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ABSTRACT 


The  risinj  cost  of  software  has  created  a  demand  for 
methodologies  which  will  allow  the  creation  or  port-ill-! 
software.  Formal  specification  methods  have  been  used  to 
increase  the  portability  of  software,  permit  a  deg  re-,  of 
verification  and  validation,  and  lessen  the  burden  of  main¬ 
tenance.  The  underlying  theory  for  most  s  q  e  ci  f  icatior. 
methods,  however,  make  them  difficult  to  use  and  frequently 
are  not  applicable  to  many  problems.  Formal  specifications 
based  on  initial  algebras  provide  a  framework  for  precisely 
defining  program  behavior  and  avoid  the  problems  cf  informal 
specification  methods.  This  thesis  presents  a  sq  e  ci  f  i  rat  tor. 
language  based  on  initial  algebras,  describes  the  various 
parts  of  specification  produced  by  the  language  and 
describes  an  experimental  syntax  directed  editor  which  uses 
the  language’s  grammar. 
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I.  INTRODUCTION 

Software  portal  Hit  y,  as  defined  by  Poole  ar.  1  Va 
l Ref .  1  ],  is  the  measure  of  the  ease  wnich  a  grcgra!  c a 
transferred  from  one  environment  to  another;  if  the  e:  f 
repaired  to  move  the  program  is  much  less  than  that  re.. ui 
to  implement  it  initially,  and  the  effort  is  small  in 
absolute  sense,  then  that  program  is  highly  p or*.  able. 

Software  portability  has  become  an  a  Lea  of  i;. t_ 
researCii  as  the  "software  crisis"  continues  to  j 
momentum.  The  less  portable  a  program  is,  the  ir.ore  w 

cost  in  terms  of  time  and  money  to  transfer  it  to  a;.ct 
machine.  One  important  impact  of  the  lack  of  portability 
that  there  will  be  little  incentive  to  create  truly  u 
friendly  environments  since  the  cost  of  producing  sue., 
system  car.  not  be  amortized  over  many  uac;. 
implementations. 

There  have  been  many  attempts  to  solve  the  p-ortai.il 
problem.  Many  approaches  have  failed,  some  up*  r  o.iche.-.  h 
achieved  limited  success,  few  have  provide!  a  fcro.iux  ?. 
methodology  for  achieving  portability.  high  level  langua 
were  one  of  the  first  atteatts  at  resolving  the  pro'.  1 
They,  however.  Were  cither  t co  small  to  be  use  "u!, 
ccnseguenteiy  extended,  or  too  large  and  therefore  subset 
Even  if  the  language  achieved  a  great  deal  of  coi.sisto 
over  many  implementation,  programs  were  still  designed  v 
non-standard,  machine  dependent  features. 

Decompilers  and  language  translators  were  ? wolopi.  u 
their  complexity  and  poor  reliability  discouca  _  ei.  burr, 
de Vc lop  ment 

The  use  of  spec  if ica tio ns  to  define  the  behavior  c 
program  is  a  method  which  offers  a  way  to  solve 


fro  a  a  specification,  the  description  of  s.rj,  ua  t  e  h  a  v ..  o  r 
can  he  more  precise  and  implementation  inde  pei.cerce  is 
possible.  Complications  arise,  however,  when  the  sp*  cifi  ca¬ 
tion  language  is  ambiguous.  Formal  s^ecificat  ior.  la:,  pa  a 
based  on  mathematical  principles  alle'/mate  tnis  pro!  her  - 
often  are  more  difficult  to  use  and  frequently  larger  ftm 
tr.a  programs  they  specify.  Despite  the  difficulty  in  ti.*ir 
use,  formal  specif ications  offer  the  greatest  decree  o : 
freedom  from  implementation  without  ambiguity. 

A  specif icat ion  methodology  based  on  initial  algal  ras 
promises  to  be  a  viable  answer  to  the  portar  Hit y  '•coble--, 
without  the  drawbacks  of  most  formal  specification 
tec  n  n  _  q  u  es . 

Algebras  have  a  wide  range  of  applications.  .'any 
researchers  have  proposed  treating  abstract  data  types  as 
algebras  [F.ef.  2],  [Ref.  3],  [Ref.  4].  Algebras  are  partic¬ 
ularly  well  suited  for  describing  data  types;  data  types 
consist  of  data  elements  and  operations  on  the  iuta  eiem.  :.t.. 
which  is  essentially  the  definition  of  or.  algebra.  Furci, 
ir.  his  thesis  [F.ef.  5],  noted  that  if  algebras  can  re  uc-.-  : 
to  specify  uata  types,  then  the  next  step  would  be  to  use 
tnem  to  specify-  languages;  a  program  is  composed  of  instruc¬ 
tions  which  can  be  expressed  using  algebras.  Furthermore, 
ZeSearcn  a t  the  !ia"ui  Postgraduate  fcnooi  is  aimed  at  using 
aigei ras  to  specify  an  abstract  machine.  A  machine  can  bo 
described  using  algebras  since  the  execution  of  instruction j 
causes  the  machine  to  change  state.  Algebras  are  used  to 
define  the  effect  each  instruction  has  on  the  state  of  the 
machine . 

*  u  t  sump  ^y ,  ry  usin  g  aigebr  as ,  normal  speamr moat  mens  car. 
be  produced  which  are  truly  independent  of  ar.  implementa¬ 
tion;  man,  implementations  of  the  specification  car.  re 
created  which  emulate  a  formal  algecraic  specification.  In 


•ii  lit  ion,  it  is 
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correctness  of  ar.  implementation  developed  from  ar.  algebraic 
specif ication. 

If  the  research  at  the  Naval  Postgraduate  School  is 
successful  in  specifying  an  abstract  aaciine,  software  can 
then  be  targeted  for  the  abstract  machine  and  freed  rrom 
machine  dependence.  A  simpler  layer  of  software  will  trans¬ 
late  the  abstract  machine'  co  mrna  nds  into  a  particular  machine 
code.  k  tremendous  savings  can  be  realized  when  eery  lex 
software/  such  as  software  that  supports  a  user  friendly 
environment,  is  targeted  for  this  machine.  Fat hermore,  it 
may  be  feasible  to  determine  if  one  abstract  machine  is 
equivalent  to  another  because  of  the  precise  algebraic  spec¬ 
ifications.  Equivalent  abstract  machines  would  imply  a  way 
of  translating  software  to  different  machines. 

The  intent  of  this  thesis  is  to  define  a  suituri-- 
ianguage  for  an  algebraic  specification  which  minimizes  th : 
problem  with  using  this  aetL oology,  and  to  i  apiem-on  t  a:, 
experimental  syntax  directed  editor  using  this  iar. guage. 
Chapter  two  provides  the  background  theory  of  specifications 
based  on  algebras.  Chapter  three  describes  the  various  [arts 
of  an  algebraic  specification  and  the  corresponding  parts  in 
the  proposed  language.  Chapter  four  describes  a  syntax 
directed  editor  for  the  language. 


II.  SPECIFICATIONS  BASED  ON  ALGEBRAS 


The  purpose  of  this  chapter  is  to  provide  an  introi ac¬ 
tion  to  algebras  used  for  specifications.  3oguer.  et  ai’- 
work  using  algebras  to  specif y  abstract  data  types  provi 3es 
the  basis  for  the  language  presented  in  the  next  chapter 
[Ref.  2].  A  review  of  definitions  and  terns  used  in  the 
algebras  they  discuss  is  worthwhile  before  introducin';  tu 
specification  language. 

A.  A  REVIEW  OF  ALGEBRAS 

An  algebra  consists  of  a  set,  called  the  carrier  of  the 
algebra,  an  operator  defined  on  the  carrier  and  distin¬ 
guished  elements  of  the  carrier,  called  the  constants.  They 
are  normally  represented  using  a  bracketed  tuple.  Tor 
example,  the  addition  operator  on  integers  would  be 
expressed  as  follows: 

<I,+  ,  3> 

The  carrier  set  can  be  of  any  one  type  we  wish  tc  manip¬ 
ulate  such  as  real  numbers,  integers  or  character  strings. 
For  the  addition  operator  on  integers,  the  carrier  Jet 

identified  Ly  the  capital  letter  I  and  the  elements  or  t..e 

carrier  set  are  the  integers.  The  disting uisned  element  uf  I 
is  zero. 

An  operation  is  a  mapping  taking  one  or  more  elements  in 
the  carrier  to  an  element  in  the  carrier.  For  example,  the 
addition  operator  on  integers  will  take  two  integers  and  map 
them  to  an  integer  as  shown  in  Figure  2. 1  . 

It  is  common  practice  to  refer  to  a  specific  class  of 

algebras.  The  members  of  a  particular  class  have  the  suae 
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j;  u:,u':s  [Ref.  2 


si gnature  or  "arity"  ir.  tutii 
instance,  the  subtraction,  a  Hitioa  an:  aiiti:  licition  c..- -or¬ 
ators  on  integers  are  members  cf  the  same  class  since  tr.e; 
have  the  same  signature;  they  aa^  two  integers  to  or. 
in  t  e  g  er  . 


Integers 

+• 


Figure  2.1  Sapping  of  Integers. 

The  constants  or  distinguished  elements  of  tat  car*  as), 
usually  have  special  properties.  The  numoer  zero  in  tin 
integers  has  a  special  property  ir.  regards  to  the  ad.iitio 
operator;  any  number  added  to  zero  will  map  ja;c  to  I:  ns. 
number  as  shown  in  Figure  2.2  .  Algebraic  specif  ica  ci  o.i. 
will  not  explicitly  deal  w  it  a  distinguished  elements, 
Instead,  constant  operators  are  used  to  describe  the  distin¬ 
guished  elements.  This  is  done  to  achieve  implement  at  io; 
independence  in  the  specif icat icr . 

An  algebra  is  not  usually  interesting  unless  it  has  sea- 
specific  structure.  The  structure  is  defined  by  axioms 
Using  the  above  example,  the  addition  operator  as  define 


Figure  2.2  A  Constant  Mapping 


will  not  be  useful  if  every  application  of  the  operator 
mapped  an  element  to  the  same  element.  Therefore  restric¬ 
tions  on  the  behavior  of  the  addition  operator  are  define  1 
which  limit  the  mapping.  Later  it  will  be  shown  how  axioms 
define  the  behavior  of  operators  in  an  algebraic 
specification. 

B.  SIGIiA  OR  MANY  SORTED  ALGEBRAS 

•> 

An  algebra  with  one  carrier  set  and  mapping  is  not 
particularly  useful  for  the  purpose  of  specifications.  -or 
instance,  ir.  defining  a  stack  as  an  abstract  ista  type  using 
algebras,  we  would  not  want  to  be  limited  to  one  tyte  o: 
data  the  stack  contains  such  as  a  stack  of  integers.  Instead 
we  would  like  to  talk  about  a  stack  of  integers,  reals, 
booleans,  etc.  Therefore  in  specifying  an  algebra  for  a 
stack,  a  'sort*  set  would  be  defined.  Each  element  of  the 
sort  set  would  be  an  index  to  a  carrier  set;  the  sort  wo  ul  1 
identify  the  carrier  set.  A  stack  data  type  can  then  be 
defined  as  having  a  sort  set  as  follows: 

S=  {integers,  boolean,  stack,  reals} 


_,tc..  tic>rt  in  the  stt  3  l  <=  .  r  tswr.  t  s  a 


CiLi  -  . 


possi  no  tc  aerine  a  staC/i.  or  r  tu  ^.s  ^  lnt^  un  ..o 

values.  Notine  that  a  stack  also  is  a  sort;  a  stack 
different  olject  after  opera  tior.s  are  performed  or.  it. 
result/  stack  is  also  a  carrier  set. 

In  addition  to  the  many  sorts  of  an  il  je;  :u,  i 
desiraLle  to  have  various  operators  on  tr  e  sorts.  ‘‘.or 
or.  the  data  type  are  defined  Ly  ra  t  pin  s;  iron  zero  or 
elements  from  carrier  (s)  to  ar,  element  in  a  carrier 
Using  tue  stack  example,  the  pusn  o*  er<_tor  Car.  Lc  ;u. 


push:  integ er / s tack  ->  stack 

The  meaning  of  this  operator  is  that  given  an  element 
each  of  the  carriers  identified  by  integer  and  stack/ 
push  operator  produces  an  element  in  the  carrier  ideut 
Ly  stack.  This  is  depicted  in  Figure  2.3  . 


•Wi 


At  e 


The  operators  ir.  a;*  aigeoraic  specifioati or  Ate  .jt»t;.  np 
a  sorted  signature,.  Sigma,  or  o£erator  domain,  wi. ich  is  a 
family  of  sets.  Each  set  of  the  family  conta_.*.s  a  partic¬ 
ular  domain  for  a  group  of  operators.  These  ail  have  the 
’'arity"  discussed  in  the  previous  section.  Using  the  st  ics 
example,  the  arity  Sigma  (integer  stac,\,sta cl)  defrr.es  a 
domain  for  those  operators  which  ma£  an  integer  and  a  stick 
to  a  stack.  The  push  operator  would  he  a  mem  her  of  this 
domain.  Ar.y  other  operator  which  took  an  integer  and  a 
stack  and  mapped  it  to  a  stack  would  have  the  same  arity. 

The  pop  operator  would  be  in  the  set  of  operators  given 
by  the  arity  Sigma  (s  tack,  sta  ck)  .  If  there  was  an  operator 
which  removed  two  or  more  elements  from  a  stack,  it  would 
also  have  the  same  arity.  An  interesting  point  her*  is  tka- 
the  integer  which  is  removed  is  a  side  effect  which  must  i\> 
described  in  the  equations  for  the  operator.  All  of  the 
operators  defined  using  the  sort  set  are  coIIac ti ve_p  known 
as  the  Sigma  signature 

Given  the  above,  a  specification  algebra  consists  01  i 
sort  set  S,  a  Sigma  signature  on  the  sort  set,  ana  named 
operators  for  each  signature.  Algebras  defined  as  such  Ait- 
called  many  sorted  algebras  or  Sigma  algebras  'Ref.  2]. 


C.  BOOLEAN  AS  A  SIGMA  ALGEBRA 

In  order  to  explain  tne  use  of  axioms,  a  development  o'. 
the  boclean  data  type  as  an  algebra  is  presented.  It  will 
specify  how  an  implementation  of  boolean  logic  should  behave 
if  used  in  a  program  or  a  machine. 

An  appropriate  sort  name  for  tne  boolean  data  type  would 
be  bool  and  the  corresponding  sort  set  S  would  be  (bool]  . 
Bool  is  the  only  sort  type  required  to  specify  tne  boolean 
data  type.  The  carrier  set  that  bool  identifies  will  contain 
two  elements  (T,F}.  Although  two  specific  elements  of  the 
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different  tions  for  the  elements  of  me  carritr  ; 

carrier  with  elements  {0,1}  would  work  equally  wei^..  In  a 
algebraic  specification,  the  elements  ol  the  carrier  are  no 
specifically  defined  so  the  implementor  may  choose  in 
representation  for  carrier  elements.  In  ms  way,  a  sped 
fier  can  achieve  implementation  independence.  dovavt-r,  :o 
the  purpose  of  clarity,  the  elements  of  the  carrier  •»  rli  • 
used  in  the  boolean  example  to  define  the  operators. 

The  five  boolean  operators  used  in  th>  ii.ec.i  rent  .  j 
will  be  as  follows. 

1.  true  -  Returns  a  value  of  T. 

2.  false  -  Returns  a  value  of  ?. 

3.  not  -  Returns  the  negation  of  a  value. 

4.  Implies  -  Implication 

5.  and  -  The  logical  ’and1  operator. 

The  following  notation  will  be  adopted  for  o;  «.  r  at  cr.-  i. 
describe  the  operand  sorts  and  the  resulting  sort. 

For  Sig ma  (lambda,  bool) 
true  ;  ->  tool 
false  :  ->  nooi 

For  Sig  ma  (bool,  bool) 

not:  bool  ->  bool 

For  Sigma  (bool  bool,  bool) 

and:  bool, bool  ->  bool 
implies:  bool, bool  ->  oool 


The  notation  here  is  the  same  as  that  used  ta  it 


u.  *0  t 


push  operator  in  the  last  section  and  will  be  t:.  a  name  no ca 
tion  used  in  the  specification  language  prcsente’.  later 
For  the  signature  Si  gma  (lambda  ,  bool),  the  notation  mean 
the  "true"  and  "false"  operators  produce  an  element  in  th 
carrier  set  identified  by  fccol.  Lambda  is  used  i 


coh  2  unctior. 


'»  —  I  ..  CO  2.o  t  U  f.  t  t  £d  Coro;  C  oil  S  Ca  i-  >'  •„  f  -  2.  t.  ^  i 

dxt'd  vs  j'lomct;  t  .I'd  same  cicjic  nt  uni  they  appear  t ’j  .re.  oc>. 
somethin j  from  notiling.  The  "net"  operator  tdfees  dr  element 
from  t..e  carrier  set  identified  Ly  uool  and  produces  an 
element  in  the  tool  carrier  set.  Ire  "and"  and  "implies" 
signature  would  be  Sigma  (bool  bcoi,booi).  Tnat  means,  given 
two  elements  in  tte  carrier  set  identified  by  bool,  the 

"and"  and  "implies"  operators  produce  an  element  in  the 

carrier  identified  by  bool. 

T he  sigaa  algebra  for  boolean  at  this  point  is  not  very 

interesting.  This  is  because  the  operators  have  no  restric¬ 

tions  on  their  behavior.  Consequently  most  implementations 
or  boolean  using  just  this  specif  ica  tion  would  not  be 
useful.  For  example,  the  "not"  operator  would  be  correct  if 
it  took  any  element  in  the  carrier  set  ana  produced  the  sa.r.*3 
element.  A  sore  useful  Sigma  algebra  would  put  r es tricti on.3 
on  the  operators.  This  j.s  accomplished  by  i  n  t  rod  uc  rn  j 
axioms  or  equations  on  the  operators.  In  t.ne  3ooiean  sigma 
algebra,  we  would  introduce  the  following  axioms: 

I.  false  =  notitrue) 

2  .  not  (not  (v)  )  =  v 

J.  and (true,  v)  =  v 

4.  ana  (false, v)  =  false 

5.  implies  (v  1 ,  v2)  =  not  (and  (v  1 ,  not  (vd)  ) ) 

botice  that  the  axioms  were  written  without  usir.  x 
explicit  reference  tc  carrier  set  elements;  l  y  not  nsitj  f 
or  F  the  uata  type  achieves  implementation  independence. 

I  mpiemej.ta  ti  ons  of  the  boolean  data  type  are  now 
required  to  mimick  the  axioms  when  operators  are  a^plic-l. 
For  instance,  the  negation  operator,  "not",  now  behaves  as, 
expected  and  any  implementation  would  have  to  reflect  axioms 
o..e  and  two.  Axiom  one  shows  the  effect  "not"  has  on  an 
element  in  the  carrier  set.  Axiom  two  rurtheL  refines  the 
behavior  of  "not"  by  showing  that  any  element  in  the  carrier 


wnich  is  o.eratt.i  or.  jj  the  "not"  .  .  . 

produce  the  same  element. 

The  "and"  operator  behaves  as  depicts!  by  euuati«.r. 
three  and  four;  given  any  value  vl  "anded"  wit:.  » h _■ 
produced  from  the  "true"  operator  will  result  t.;.  it  v  .h:- 
Implies  is  defined  by  axiom  five  as  Le^ng  ti;e  s_t-; 
combination  of  "not"  and  "and"  operators  asrsj  .• 
carrier  values. 

liote  that  with  the  exception  of  axiom  j .. • . ,  ul 

axioms  involve  variables  v,  vl  and  vl  which  >ra r.  jcsi.  :..t 

all  values  from  the  carrier  set  defined  for  the  oper  at  or 
"and"  "r.ot"  and  "implies".  The  axioms  form  tar  oasis  o:  n 
the  expressions  that  can  be  created  using  the  variables  ij 
members  of  the  carrier  set.  This  means  that  an  expresaio 
which  is  built  from  other  expression  is  per mis  sable  if 
reduces  to  an  element  of  the  carrier  set  tnr^i::.  c 
application  of  the  axioms. 

To  illustrate  this,  suppose  we  had  an  expression 

not  (and  (not  (v  tj  ,  v2) ) 

If  vl  is  assigned  the  element  I  and  vl  is  assign*!  t 
element  F,  then  the  expression  becomes  the  following 
axiom  cne: 


not  (and  (F,f)  ) 

Inis  further  reduces  to  not(F)  by  axiom  four.  Axiom  on 
implies  that  this  reduces  to  T,  an  element  of  the  carrier. 

All  the  permissible  expressions  tnat  can  he  construct*: 
from  the  operators  and  elements  of  the  carrier  arc  collec 
tively  called  the  term  algebra .  The  algebra  that  rt  present 
ail  the  expressions  that  can  be  made  ut  of  van  an  he  *  ij. 
operators  is  called  a  free  algebra  [Ref.  2  J. 

It  is  now  possible  to  define  a  specification  as  a  %  rec¬ 


ent  at  ion" 


A  presentation  consists  of 


a 


sort  set. 


III.  A  SPECIFICATION  LANGUAGE 


liskov  and 
evaluating  a 
i'ocuses  on  the 
cation.  They 
state  machines 
criteria  used 


Silxes  [Ref.  4]  have 
formal  specif ication 
underlying  mechanism 
compared  approaches 
,  mixed  mathematical 
in  their  comparisons  a 


developed  criteria  re 
language.  Their  c  ~r 


use 

foi  sal 

■•C'Ci  Li 

sing 

ai 

C  rliS  / 

fin  it 

disciplines ,  etc.  Ih 

t: ; 


1.  Formality  -  The  language  must  re  p r ec in 
rigorous. 

2.  Constructability  -  It  should  be  easy  to  construct 
specification  from  the  language. 

3.  Comprehensible  -  Is  the  specif  icatior.  relatively  e  is 
to  understand? 


4.  minimality  -  The  specification  generated  shoui 
define  its  meaning  with  a  minimum  number  of  state 
nents.  One  flaw  of  formal  specif  ica  taoi.s  is  that  the 
frequently  require  more  statements  that.  tne  projra 
they  specify. 

5.  applicability  -  Can  the  a-an^uaje  oe  use.  ror  a  wi.i 
range  of  specifications? 

6.  Extensibility  -  A  minimal  change  in  concept  result 
in  a  similar  smal..  cn  an  g  e  in  a  specirica^ie... 

The  rigorous  underlying  mathematics  for  dig  ras  satire 
ti.e  formality  criteria  and  the  axioms  restrict  tne  amount  o 
information  required  to  explain  desired  behavior,  h.u 
satisfying  minimality.  Also,  it  appears  that  any  do  sir*, 
change  in  behavior  requires  a  minimum  of  additional  axiom 
or  minor  modifications  to  the  existing  on=s.  As  cor  applies 
bility,  algebraic  specifications  are  bti  **  j  vl  ti  Cm  1  ^  1  ll  i.  t.  i  vlk* 
machines,  data  tyres,  and  programming  languages,  vL  cc 
indicates  a  wide  range  of  applications. 
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of  tit  diove  criteria  except  couprehensibi  it  y  ari  cc..  ^tract- 
ability.  These  deficiencies  can  be  reduced  to  a  manageable 
level.  The  following  proposed  language,  Speclan3 ,  will  mini¬ 
mize  these  problem  areas.  In  this  chapter,  it  wall  be  show:, 
that  a  complex  specification  can  Le  modularized;  broken  into 
smaller  units  which  enhance  cons  tructanility  an; 
comprehensibility. 

There  are  many  underlying  issues  involved  in  usir..,  aige- 
bras  for  specifica tions  which  have  not  been  resolv-i. 
Issues  such  as  proving  speci fications  correct,  infinite 
versus  finite  specifications,  implementation  and  et..-..; 
complex  issues  will  net  be  addressed.  The  following  _«~ctj 
are  to  ramiliarize  tut  reader  w  it  u  the  ^raiuuar  xoi  5  p  v<.  *  a ..  i , 
parts  of  a  specification  produced  from  the  Spec  la n-  grammar 
and  a  brief  explanation  of  the  uses  of  the  various  parts. 


A.  SPECLANG  GRAMMAR 

Before  presenting  the  various  parts  of  a  specification 
constructed  from  Speclan.,,  an  introduction  to  the  grammar  is 
presented.  Appendix  A  contains  the  complete  grammar  io.. 
Speclang.  The  production  rules  are  written  x  l.  d  .u  O  U  ±  L  '1 
Eackus-Naur  { 3  N  F )  notation.  The  meta-symbols  ir.  the  .cciuc- 
tion  rules  are  used  tc  fora  the  construction  o;  a  st  ec^-i 
tior.  and  do  not  appear  in  the  final  specification.  An 
explanation  of  the  meta-symbols  used  to  produce  termirax 
strings  in  the  grammar  are  as  fellows: 

<  >  -  A  name  enclosed  by  pointed  brackets  indicates  a 

non-terminal  in  the  grammar. 

'  '  -  Strings  in  ^.uotes  indicate  terminal  strings. 

(  )  -  Rounded  brackets  indicate  the  scope  of  a  modifier 

symbol. 
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Ll  icx€  to  i  1' jl' d i r* >j. i ^  on  r. o r*  —  x.  m  iii a ±. s  •  it  " f-  .1  r. s  *  .’.i.*  e  .  1  r^_  ^ 
acre  of  the  expressions,  terminals  or  non- terminals  ray  i 
prod  ucei . 

+  -  The  alternation  modifier  is  used  like  the  riet  ro  ri 
fier .  It  means  that  one  or  more  of  the  expi tsS . ox  t 
terminals  or  non- ter minals  may  Le  product!. 


The  selection  modifier  indicates 


c,.  ce  (v 


terminals,  terminals  ci  expressions*  it  is  us*r  n  .10 .  » <  n  „ 
choices.  In  order  to  clarify  the  selection,  rour.lt:..  '  i'..ch- f: 
enclose  the  selection. 

?  -  Che  option  modifier  indicates  that  the  rern_:.ai, 

non-terminal,  or  expression  is  optional  and  can  be  exci Jutd. 

->  -  Che  production  symbol  indicates  what  the  no::- terminal 
on  the  left  hand  side  can  produce. 

A  production  rule  consists  of  a  non- terminal  follow*.,  b; 
a  production  symbol  followed  by  an  expression.  An  ex  press; o: 
is  comprised  of  terminals,  non- terminals ,  medaiyinp  ;>:;lo.w( 
•and  may  include  other  expressions.  Che  fellow  in.,  irowuccio. 
rule  will  be  used  as  an  example  througnoul  the  remainder  o: 
the  thesis: 

<moauie_spec>  ->  <spec_header> 

(<newline>< indent><param_block>i  7 
<  new  line  >  <i  n  den  t  >  <s  pe  c_  ho dy  > 

This  rule  defines  a  specif icati on  module.  The  module  woui 
begin  with  a  specification  header  followed  by  an  ojtioi'a 
expression  that  contains  a  carriage  return,  ii  de t  atio:. 
a  parameter  block.  Because  it  is  an  optional  ex pressior ,  ;■ 
may  be  omitted.  After  the  expression,  another  carr.ag. 
return  and  indentation  occurs  followed  by  a  s; t cif rcatioi 


h  1  rr  I.  t  ..1  7  IO 


The  jra?.3di-  for  Steeling  xi. elides 
caciiauc  returns  to  jers.it  a  rorsiattu.no  ot  tr. t  st  deifica¬ 
tion  .  This  was  done  to  create  a  standard  icrmat.  which  will, 
hopefully,  increase  the  readability  of  a  specif ication . 

A  specification  is  complete  when  ail  the  strings  i..  the 
specif  ication  are  terminal  strings.  Inis  is  accort  1  ishei  by 
starting  with  a  nonterminal  ana  substituting  the  expiecs-ici. 
at  pearing  on  the  right  hand  side  of  its  productioi  rule.  Th«; 
remaining  nonterminals  are  tiien  substituted  until  all  tnc- 
strings  are  terminal  strings.  For  example ,  starting  with 
the  nonterminal  <module_spe c>  and  substituting  tie  right 
hand  part  of  its  rule  results  in  tne  following: 


<s  pec_heauer>  (<newline><  indent  ><  par  a  m_.doc  k  >) 
<nevline><indent><spec_body> 


The  rule  for  a  specification  header  is: 


<sp  ec_hea  der>  ->  ’SPEC’  <spec_id>  'IS' 

,  Its  right  hand  side  is  substituted  into  the  right  hand  s_do 

of  the  above  strings  to  produce: 

'SPEC*  <spec_id>  'IS1  (<new_line>  <indent>  <parac_i-.ock>#' ? 
<newline>  <indent>  <spec_body> 

i 

<nevline>  and  <ir.der.t>  can  be  interpreted  as  carriug-  riturn 
ard  a  tab  respectively,  except  when  it  follow*.-''  by  a 
modifier,  and  make  the  developing  specif ication  appear  os: 

!  SPEC  <spec_id>  IS  (<newline><indeatXpar<iiu_biock>)  ? 

<spec_body> 

In  the  lexical  grammar  for  Speciang,  <inder.t>  is  treated 
^  either  as  one  or  more  tabs  or  spaces.  This  was  Ion*  to 

permit  the  degree  of  indentation  a  specifier  desires.  Oi.ct  a 
indentation  has  been  selected,  it  should  be  continued 
throughout  the  specification.  For  instance,  if  one  tab  is 


use-  to  iratiit  d  j.j.i.0,  tr.en  evtty  tii3  ir.;er  t  is  encoun'.^rt1  ; 
or.e  tab  should  bt  used. 

Since  <par am_biock>  is  optional  it  can  be  eliminated  to 
prod  uce : 

SPEC  <spec_ii>  15 
<spec_  tody> 

The  substitutions  are  continued  until  ail  strings  are 
composed  of  terminal  characters. 

The  first  nonterminal  strin  g  in  Sped  ant  is  <oce  p_spc-c>  . 
This  denotes  a  complete  specification.  \s  mentioned  in  the 
previous  section  a  specification  developed  from  Speciar.g  is 
made  up  of  modules.  Each  module  in  itself  is  a  specifica¬ 
tion.  To  reflect  this  the  right  hand  side  of  the  production 
rule  for  <comp_spec>  is  <moduie_spec>*.  In  other  words,  a 
complete  specification  is  made  up  of  one  or  more 
specification  modules. 

B.  PABTS  OF  A  SPECIFICATION 

As  mentioned  in  the  previous  section,  a  complete  speci¬ 
fication  is  made  up  of  one  or  more  specif icat ion  nodules. 
Each  specification  module  is  an  algebraic  specification, 
which  can  be  viewed  as  a  s utspecif ication  of  the  complete 
specification,  and  has  three  distinct  parts  -  tracer,  signa¬ 
ture,  and  axiom  parts.  Each  specification  module  xs  ■e.t.ir: 
"primitive",  "extended"  or  "parameterized'1.  Primitive 
modules  do  not  import  other  specification  uo  iui-.s  v.  lie 
extended  modules  do  import  other  specif  ica  ?  ior.  modal  .e  to 
create  a  new  specification.  "Parameterized"  modules  ar«. 
used  to  minimize  a  specification  and  can  be  either  pr;.  :.;.t Iv¬ 
or  extended. 

A  specification  is  started  with  primitive  modules.  These 
modules  are  used  to  create  other  modules  throe- n  the 
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ficution  r.oJalt  defined  in  a  Cwxpiete  speci  1 1  ci*.  i  on,  i 
effect,  consists  of  all  the  other  specif icalion  monu_eS 
since  it  is  built  from  the  previous  nodules.  I  ho  ioi.iowrh-; 

section  describes  and  discusses  each  part  of  a  s;  ecifio ntio:. 
module. 

1 .  Header 

The  header  identifies  the  name  of  the  n  peer  fleet  10 .. 
and  soaetimes  contains  a  "codifier".  "Pr  im-  tivs  "  no-..uI>.s  i .. 
Spec lan;  contain  no  codifiers  ar.d  the  forrat  is  as  follow.-: 

SPEC  <spec_id>  IS 

(signature  part} 

(axiom  part} 

<spec_id>  is  a  slot  for  the  particular  name  of  that 
declared  specification.  The  tody  of  the  specification,  wh^ch 
contains  the  syntactic  and  semantic  part,  follows  ur  dorr.eath 
the  header.  When  used,  the  modifier  is  directly  unaer  the 
header.  Its  purpose  is  to  import  other  specifications  into 
the  declared  specification.  The  modifier  is  tre  prii  ^;:y 
method  used  to  combat  the  complexity  of  an  -ai; nsraic  speci¬ 
fication.  It  will  be  presented  after  the  other  i arts  oi  the 
specification  are  introduced. 

2  .  Signatur e  Part 

The  signature  part  of  an  algebraic  specificat ion 
contains  the  declarations  for  sorts  and  operators  nr.  : 
defines  the  format  and  composition  of  the  Operators.  It 
corresponds  to  the  signatures  discussed  in  chapter  two. 

a.  Sort  Declarations 

In  Speciang,  the  format  for  declaring  sorts  is: 

SPEC  <spec_id>  IS 


<sor  t_ia> ; 

<sor  t_ii> ; 

<sort_id>  is  the  slot  for  a  particular 
name.  As  explained  in  the  previous  chapter,  t  i.e  sort 
identify  the  carrier  (s)  used  in  the  operators.  All  o 
sorts  declared  under  the  header  SORTS  define  the  sort  s 

b.  Operators  Declaration 

The  operators  declaration  can  contain  up  tc 
different  t} pes  of  declarations: 

1 .  Primi ti ve 

2.  Derived 

3.  Hidden 

4 .  Error 

These  operator  type  names  are  usea  as  headc- 
eich  group  of  operators  declared  in  Specian-j.  The 
format  for  an  operator  is: 

<op_ia>  :  <sort_id>,  <sort_id>  ...  ->  <so rt_r:> 

An  operation,  as  explained  in  chapter  II, 
map  zero  or  more  elements  from  a  carrier  set  (sj)  ident 
by  the  sort  r.ame(s)  to  an  element  of  a  'carrier 
identified  by  the  sort  name. 

A  specification  with  sorts  ai.  d  o4 a  rat  ore 
appear  as  follows: 

SPEC  <iaentifier>  IS 


<sor t_id> ; 
OP ER  ATIO  NS 

PRIMITIVE 


<op_id>:->  <sort_id> ; 

<op  id>:<sort  id>,<sort  i  i>  ->  <soi 


<o*._id>:  <scrt_id>  ->  <sort_ii>; 

ERE  C  E 

<op_id>;  <sort_ia>  ->  <sort_id>; 

JEF.  IVED 

<op_id>:  <sort_ia>  ->  <sort_.i.i> 

(1)  Primitive  Operators.  Primitive  c  * LuLor 
are  newly  defined  operators  and  cannot  be  cones  true  ted  iron 
any  other  operators  such  as  the  derived  operator  utuci.iit  ! 
next.  Primitive  operators  may  involve  sorts  fr^m  ot.ler 
specification  modules  and  usually  contain  at  least  one  srL-, 
from  the  specification  ir.  which  they  are  declarer. 

(2)  Derived  Operators.  Derived  aptratoii  ar r. 
operators  which  can  he  produced  from  other  operators.  T..ey 
are  declared  so  the  implenentcr  of  the  sped  f  ica  c  10^  is 
aware  that  their  existence  is  rot  essential.  Idr  1  ast  .'.»ce , 
in  the  boolean  specification,  if  the  "not",  !'ini"  ana  "or" 
operators  are  defined,  it  is  not  necessar*  to  ir.cd  u  ie  ar. 
"implies"  operator  since  in  predicate  ioqic  "imj-Iies"  is 
equivalent  to  "not"  A  "and"  L.  The  ner.ef  it  ir.  hav  ir...;  a 
derived  operator,  such  as  "ia.tIios",  is  to  sinicize  tie- 
specification  and,  in  many  c^ses,  make  the  specification 
more  comprehensible.  In  the  iooltan  e$aai  it,  "implies"  is  a 
well  understood  operator  and  usinj  it  in  otnet*  specification 
modules  will  make  the  modules  mere  readable  than  if  a  cuui  i- 
nation  of  "not"  and  "or"  were  used.  "implies"  would  be 
declared  under  the  DEEIVED  header. 

(3)  Err  or  Operators.  The  proper  nandiirj  of 
errors  is  crucial  tc  a  specification.  However,  it  is 
frequently  the  case  that  speci f icat ions  for  lanjuaaes,  data 
types,  proqraas,  etc.  do  not  precisely  define  what  shoula 
happen  when  an  error  is  encountered.  This  is  carte  blar.c«.e 
for  the  implementor  to  do  what  he  thinks  is  appropriate.  In 


nOC-.-i.iij  US  UOnO, 


€  c  x  c  c  : 


consequences. 


A  specification  should  adiress 
circums tances  where  the  operator  cay  not  sake  sense  on  tne 
operands  and  define  precisely  how  to  handle  tnen.  .-.r 
example,  in  the  specif icat ion  for  a  data  type  "stock''  os 
integers,  the  sorts  and  operators  would  he  as  follows: 

SPEC  Stack  IS 

SO  SIS 

int ; 
stack ; 

OPERATIONS 

PRIMITIVE 

new:  stack; 

push:  int,  stack  ->  stack; 
pop:  stack  ->  stack; 
top:  stack  ->  int; 

The  "new"  operator  creates  an  empty  stack 
and  the  "push"  and  "pop"  operator  hehave  as  wculu  he 
expected.  The  "top"  operator  allows  tue  user  to  view  the  to: 
element  of  the  stack. 


Problems  occur  when  a  user  attempts  to 
"pop"  a  "new"  stack  or  view  the  first  element  of  a  "mw” 
stack.  These  are  valid  operators  since  "now"  ret  urns  a  ct  ... .. 
and  the  "pop"  and  "top"  operators  are  defined  on  a  stack. 


returns  .1 


t:  on 


tUCK. 


It  would  seen  reasonable  to  introduce 


value  "error"  to  each  carrier  set  to  define 


-rror  sen  ;i- 


tions.  Guttag  [fief.  3]  proposed  this  approach.  The  result 
would  be  equations  which  specify  wnat  are  error  coi.uit  i  j;.s . 
Axioms  pop(new)=  error  anl  top(r.ew)  =  t-rrur  wouis  ^n  ii.  ..1  \ 
resolve  the  problem.  Guttag  also  repaired  equations  w:. j.c ! 
defined  the  propagation  ox  errors.  Therefore  pus  h  (error  ,s)  = 
error  and  push  (n , err  or)  =  error  would  be  introduced  into  the 
suecif  ication. 
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top  (push  (n,  error) )  =  n  and  top  (push  (n, error)  )  =  error  car.  be 
produced  from  the  axioms  which  imply  n  =  error  r  or  any  n. 

The  approach  adopted  in  Speclang  it  the 
one  used  by  Easel  and  developed  hy  Gopier.  [Ref.  2].  Toms 
involves  introducing  error  operators  into  the  st  >. cif: ica  ti o.. . 
These  operators  will  produce  error  messages.  In  the  steel 
operator,  we  would  define  error  operators  "  topr.ev'  ana 
"underflow"  which  produce  carrier  values  inlt-jtr  v.d  st  ;.;i. 
respectively  and  also  generate  error  messages.  In  Jpeclra ; , 
the  error  operator  will  be  declared  under  the  error  operator* 
title.  Using  the  stack  specification,  the  declaration  would 
he  as  follows: 


SPEC  Stack  IS 
SORT 

int ; 


stack ; 

OPERATIONS 

PF.IiilTIVZ 

new : 

->  stack; 

push  : 

int,  stack  -> 

pop; 

stack  ->  stack; 

top; 

stack  ->  int; 

ERF.  OF. 

topr.ew:  ->  int; 
underflow:  ->  stack; 


The  axiom  portion  of  the  specification 
would  use  these  operators  to  define  error  conditions. 

{h )  Hidden  Operators.  Unfortunately,  it  is 
not  always  possible  to  have  just  operators  for  the  user. 
Some  operators  are  required  in  order  to  define  the  user 
operators.  Hajster  demonstrates  this  with  a  stac*. 
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i.  i lC-it  ioii  w ic u  —  li c _i- 1  to j  o^t  i.*i  tors  t. r. e.  l  .  j  v  . t  <■  -  * ^  .  i’ 
to  view  ax*y  eitsen:  of  the  s  tacx  wit  bo  at  -  *..=  car..x;.  3  t*.  o 

stack.  [P.ef.  6].  In  order  to  define  these  o;oritois,  it  is 
necessary  to  define  a  "current  position"  which  point  to  i 
particular  element  in  the  stack,  not  necessarily  the  con 
element.  The  new  operators  are  "down"  which  moves  che 

current  position  down  one  element  in  the  stack,  "re  i  i.:n  ’ 
which  moves  the  current  iOsiticn  to  the  top  of  t..e  st^h, 
and  "read"  which  will  give  the  Value  of  tne  o_o»ienl  at  .'*•  Lei. 
the  current  position  is  pointing.  Pus:*,  for  ar.i  top  can  ot.ry 
he  done  when  the  current  position  is  on  t*.»  top  *• 

Using  just  the  operators  availalie  to  the  user,  it  op.  v  .  er: 
that  an  infinite  numier  of  equations  are  re  puree  to  u*  f  i...; 
the  meaning  of  reading  each  element  of  tne  jtaco.  (if  t.-  ;• 
stack  is  considered  ar.  infinite  specification).  dh. 
following  are  just  a  sample  of  the  equations  required: 

read  (push  (nO,  L)  =  nO 
read  (down  (push  (nO,  p  ush  (n  1,  L)  ))  )  =  nl 
read  (down  (down  (push  (nU,  ^ush  (n  1,  pusn  (na  , L) ) )  )  )  )  =  :\2 

Enumerating  all  the  required  equations  i... 

not  particularly  enlightening  for  the  implement  or  and  is  a 

» 

gross  violation  of  liskov  and  Zilies  minimality  criteria. 
To  solve  this  problem,  hidden  operators  are  inti  educe  l 
[Hef.  7].  In  Majster’s  stack,  fusel  proposed  u.ir.-j  a  hi.ilen 
operator  "append".  Append  adds  a  new  element  to  the  top  of 
the  stack  without  changing  the  current  position.  If  the 
current  position  is  at  the  to[  of  the  stack  then  append  has 
the  same  effect  as  push  followed  oy  down: 

append  (n,new)  =  dewn  (rusi*  (n,  new) 
append  (n2  ,  p  ush  (n  1,  L)  )  =  down  (pusn  (n2,  pusn  (n  1  ,L)  )  ) 

If  the  current  position  is  other  than  the 
top,  then  axioms  would  show  that  appending  is  unattached  to 
the  3cwn  operator: 


'i  pp  e  I.  { *  *  /  k*  C  m  i-  ^  — )  )  -O  wA  (jj'pCi  J  ^..  t  n)  ) 

The  read  operator  cun  t  her.  be  Gc.tir.tJ  i: 
terms  of  the  read  and  push  operators: 

read  (push  (n  ,1) )  =  r. 

read  {append (a, L))  =  read  {L ) 

Aptex.d  would  r.ot  oe  an  operator  availarl; 
to  the  user.  Its  creation  was  to  allow  a  finite  sicci^r:- 
tion  of  an  otherwise  infinite  Specif ica tion.  Hidden  opera¬ 
tors  like  append  would  be  declared  under  the  neacer  HID1I! 
to  alert  the  specifier  of  its  special  use. 

Hidden  operators  present  problems  when 
overused.  In  particular,  they  suggest  an  implementation 
£Hef.  5].  The  append  operator  is  an  example  of  this.  I:... 
read  operator  problem  may  be  solved  in  ways  other  than  usin j 
append  that  is  less  suggestive  in  an  implementation. 

In  Specian^,  hidden  operators  are  declare  1 
under  the  "HIDDEN"  header. 

3  •  Axiom  Pa  rt 

The  axiom  part  implicitly  describes  the  beha.'io.. 
the  previously  declared  operators.  It  is  the  nose  dimcui- 
por^ion  of  a  specification  to  construct;  developing  the 
axioms  tc  reflect  only  the  desired  behavior  and  no  more  is 
tricky. 

In  Speclang,  the  equations  wi ich  define  operator 
behavior  are  placed  below  the  header  "AXICH".  Tue  vaaidiiico 
used  in  the  operator  are  assumed  to  be  of  sort  types  isei  ;r. 
the  declaration  of  the  operator.  The  format  for  axioms  is 
as  follows: 


SPEC  <spec_id>  IS 
SORTS 


sort  1 ; 
OPERATIONS 


op 1  :  scrt 1->  soil ! ; 

AXIOMS 

op  1  (x  1)  =  x  2; 

The  equations  are  composed  o £  a  left  sice  ar  i  \ 
riyht  side  separated  by  aii  ecual  sign.  The  eyuai  si;,;.  ..oe., 
r.ot  aear.  the  two  sides  are  eyuai.  It  signifies  char  t..>. 
ttras  that  are  produced  from  the  operations  or  eac;.  side  are 
in  the  same  ejUivaler.ee  class.  Although  this  is  an  important 
concept  for  the  underlying  theory  of  algebraic  specifica¬ 
tions,  it  is  not  vital  to  the  person  developing  a  steciricu- 
tion.  Another  way  of  viewing  equations  is  that  each  operator 
is  defined  by  an  equation  that  shows  wnat  happens  w..cr.  the 
operator  is  applied.  Tor  example,  in  defining  Li;  e  "rush" 
operator  on  a  stack  5,  we  would  want  to  show  that  for  ary 
element  e,  push  {3, e)  produces  a  stack  with  e  on  top.  The 
specifier  should  know  that  the  top  of  a  stack  is  also 
related  to  the  "pop"  operator.  The  solution  then  in  defining 
"push"  is  to  relate  it  to  the  "pop"  operator  as  follows: 

pop  (push  (e, 3) )  =  e 

The  implicit  definition  of  Lena vior  through  alge¬ 
braic  axioms  provides  independence  from  implementation  cut 
also  creates  problems  ir.  constructing  a  specification. 

4 .  Modifiers 

When  developing  a  complex  program,  a  programmer  will 
modularize  functions.  The  benefits  are  a  more  readable 
program  and  the  program  is  easier  to  develop  and  maintain. 
An  algebraic  specification  using  3  peciani  also  car.  be 
developed  this  way. 

Burstaii  and  Goguen  [Kef.  3]  presented  a  structured 
language  which  effectively  breaks  a  specification  into 
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modify  rrevious  specifications.  Jasd  used  tneir  theory 
building  modifiers  to  develop  uis  specif  ic  atior.  oi 
pro;ram.  The  fro posed  modifiers  to  accomplish  this  „er 
cj.i  .l  iia  i  *.r.  ijjt'i  e  *  t  e  r  *  and  ivt*  u  so  s  ui.x  y  l  .. 

fa  t  -■  r.  1  a  o  -  i**t  *  to  create  sped  fica t  ions. 

‘i  t  *  r.d  modifier  adds  Lev  o  r..  t s  ,  eiaa  ■:...  o  . 
a:.!  sea.  t  ise  s  s  or  t  s  to  a  specification.  "art  her  no  re,  fh 

ext  e.'.ij  .o'.i.’iei  a  _  '  o  «  S  tie  Specifier  tO  .’OahU.e  two  OC  SuZ 

imported  o,iji:..attioiis  to  create  the  i.cv  si  ecii  ica-:i  an 
^  he.',  two  or  core  : ;  p  e  c  l  z  ic  a  1 1  or  s  are  cour  ±r.ei,  a  x  x  of  t  a  ei 
sorts,  operators,  ar.d  axioms  are  lumped  together  to  form  t:. 
r.iv  specification;  t,.is  method  is  a  shorthand  way  o 
defining  the  sorts,  operations,  and  axioms  which  aini.aiz 
the  specif icatioa. 

In  order  to  show  the  use  of  the  extend  ood_fit 
without  combining,  Easel's  example  of  the  Katun 
specification  is  presented: 

SPEC  Natural  IS 
SORTS 
nat ; 

OPERATIONS 

zero : ->  nat  ; 
slice:  nat  ->  nat; 

vie  can  extend  the  specification  with  addition  an 
multiplication  to  create  a  new  Specified tion  Natplus: 

SPEC  Natplus  IS 
EXTEND 

Natural ; 

WITH 

OPERATIONS 

PRIMITIVE 
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muit:  nat,r a:->  mat; 

AXIOMS 

add  (n, 0 )  =  n ; 

add  (succ  (m)  ,  ?.)  =  sacc  (add  (n,  3;  )  ; 

mult  (0  ,  nj  =  0  ; 

The  exterd  modifier  draws  in  ail  the  ot  erntor 
axioms  and  sorts  from  the  specif ication  name  zoilowi 
extend  and  in  this  case  from.  Natural.  Additional  soar 
operators,  and  axioms  are  included  foliovinj  the  sea: ; 
"WITH". 

It  the  extend  modifier  has  used  to  comi.  ine  sped.: 
cations  as  well  as  include  new  sorts,  oper  d  ion 1 
axioms,  then  llatplus  could  have  been  extende  d  witr:  sped, 
cations  Boolean  and  Natural  to  produce  the  i'cilovi 
specif  ication: 

SPEC  Nat pi  us  IS 
EXTEND 

Boolean  ; 

N  atural ; 

WITH 

OPERATIONS 

PRIMITIVE 

add:  nat,hat->  nat; 
multiply:  nat,nat  ->  cool; 
eoualto:  nat,nat  ->  tool; 
if_then_eis e:  uool ,nat , nat  ->  sat; 

AXIOMS 

add  (n,  0)  =  n; 

add  (succ  (m)  ,  n)  =  succ  (add  (r. ; 
multiply  (0  ,  n)  =  0  ; 
multiply  (n  ,  succ  (a)  )  = 

add(n,  multiply  (n,m)  )  ; 
eyualto  (0,succ  (m) )  =  f  alse; 


e^Udj-to  ( J,  j )  =  true; 

e guaito ^m, m)  =  true; 
if_then_else  (T  ,v  1 ,  v2) 
if_then_eise  ( S  ,v  1 ,  v2) 


In  this  cast  we  have  two  specif ications,  Boolean  and 
Natural,  which  are  used  to  define  the  Uatplus  specif  ieaticr . 


)ecif ications  declared  by  tna 


;at  ifiers 


between  "BXTSND"  and  "KITH"  are  combine  i  to  produce  the  new 
specification.  In  addition,  new  sorts,  operators  and  equa¬ 


tions  are 


lefined  on  the  combined  specification. 


an  a  ar  e 


declared  following  "KITH". 

Although  the  Hatplus  specif ication  cou.il  havt  ate:, 
easily  defined  without  tne  extend  modifier,  a  larger,  more 
complex  specification  would  be  difficult  to  real  and  pi.cb- 
ably  impossible  to  understand.  For  example,  t.ie  an  struct 
aiacnine  specification  described  in  chapter  I  has  one  speci¬ 
fication  module  which  represents  toe  final  specif aca ti or. . 
Its  extend  modifier  combines  four  other  specif ication 
modules  and  extends  them  with  approximately  one  nunliei 
other  operators  and  seventy  equations.  if  this  machine  vu-t 
described  without  the  extend  aodnfier,  then  each  of  tne 
combined  specification’s  sorts,  operators,  and  axioms  vouli 
have  to  be  included  in  the  specification.  Since  eac..  of  tn  - 
combined  specifications  were  also  extended,  each  ci 
specifications  imported  to  create  them  would  also  be 
included.  The  result  would  be  a  sp  ecif  icatio n  contain  ing 
hundreds  of  operators  and  equations,  making  the 
specification  incomprehensible. 

Before  a  specification  can  use  another  sg.-eoific  it  io„ 
ii:  the  modifier,  the  specification  being  imported  rust  ..a/e 
already  been  declared.  In  the  above  example,  UatyLus, 
Boolean  and  Natural,  would  have  already  been  declared  ir.  the 
complete  specif icaticn. 


Gr.e  metros  oi  Dir. imi zm ^  a  s^ecinc  is  tbrou g;. 

the  use  of  parameterized  modules.  Gojuen  suggestel  ends 
technique  and  Ganzinger  [Ref.  9'  explored  it  in  depth..  Ihe 
basic  concept  is  to  use  a  procedure  like  spar  ificu ti  On  to 
create  a  new  sp  ecif  ication.  This  is  a  t  artiou  ia rip  as-.fu_ 
technique  when  many  stecif icati ens  ter.l  to  re  repeated  such 
as  in  the  case  of  a  list  of  integers,  characters,  r e ; r 
numbers,  etc.  Instead  of  a  specification  f  »:*  ;jc!  •;  y __  .=  oi 
element,  a  generic  template  would  be  used  to  itacr  L.  ;  .  a*  . 
list  of  a  particular  type  should  behave.  The  pura..e  r  e  :: .  1 

specification  for  lists  can  be  invoked  by  passing  the  s; 
ficatior.  for  reals,  integers,  characters,  etc.  prod  uci/ij  a., 
instantiation  of  the  parmeterized  specification  which  is  ^ 
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new  specif icat ion. 

dany  issues  are  still  unresolved  i:.  ira...etertre  I 
specif icatior.  which  will  not  be  addressed  ner-.-  [Bef.  9]. 
Before  using  parameterized  specifications  these-  issues 
should  be  understood. 


The  parameterized  module  consists  oi  two  pri-  ity 
parts.  These  are  the  parameter  block,  and  the  spe  linear  _on 
block.  The  parameter  part  of  a  specification  ce  fines  w..  it. 
may  come  inside  a  parameterized  module  during  an  Instantia¬ 
tion.  An  instantiation  is  tne  passing  of  an  act  nil 
specification  to  a  ^arametenz  e-u  >pociiicat  non. . 

The  parameters  can  be  viewed  as  the  interface  to  the 
outside  module  which  is  invoicing  tae  procedure.  It  consists 
of  sorts,  operators,  and  axioms  and  is  announce.;  by  z ho 
header  "RARAdETT RS" . 


The  specification  part  is  like  thv.  specific.,  .o. 
body  used  in  primitive  specif  icat  Lor  modules.  It  con  hut, 
of  sorts,  operators  and  lxioiis  and  is  leciared  b  y  th*  h*-  u  a  ; 
"DBF INTO  3 Y "  . 
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formal  [aoeter1  s  sorts,  operators  a  ad  axioms  arc  rep  i  ic-.-  1 
by  the  actual  paraneters  passed  froa  the  designated 
specif  ic  at  ion. 

In  Speclang,  the  ioreat  for  a  p ararete ri tea 
speci f ieation  would  appear  as  fellows: 

5  PEC  <ider.  tif  ier  >  IS 
PA  RAM  HE  Hi 
SORTS 

<sort_  tody  > ; 

OPERATIONS 

<op_hocy>; 

AXIOMS 

<axioj_body>; 
u Ef INTO  BY 
SORTS 

<sort_tody> ; 

OPERATIONS 
<'op_tody> ; 

AXIOMS 

<ax iom_loiy > ; 

Ganzinger  illustrated  paraaet eriz ed  specifications 
by  using  the  list  exaapie: 

SFEC  lists  IS 
c  AF.  AMZTZRS 
ENRICH 


Boolean  ; 


5ITH 


5GF.  IS 


eleu  ; 

OPERATIONS 

PRIMITIVE 


equal:  eleu , elem  ->  bool; 


i f-t her.- e is e  :  oooi,  eles  ->  el  ; 

AXIOMS 

equal(e,e)  =  true; 

DEFINED  BY 
SORTS 
list; 

OPERATIONS 

PRIMITIVE 

iempty:  ->  list; 
isempty:  list  ->  bool ; 
cone:  eiem,list  ->  list; 
edr:  list  ->  list; 

if- t hen-eise :  bcoi,  list,  list  ->  list; 
first:  list  ->  list; 

AXIOMS 

cdr(lempty)  =  iempty; 

edr  (cone  (e,  1)  )  =  1; 

car  (if  _then_else  (t,  11 , 12)  ) 

=  if_then_else (b ,cur  (11)  ,cdr  (12)  )  ; 
isempt  y  (Iempty )  =  true; 
isempty  (cone  (e,  1)  )  =  false; 
isempty  (if _then_else (0,11,12) 

=  if_tiiea_else  (b,  isempty •(  1 1)  ,  isempty  (12)  )  ; 
first (iempty , e)  =  e; 
f  irst  (ccnc  (e,  1)  ,  e ’)  =  e; 

first  (  ix_then_fcise  (L,  i  1,12)  ,e) 

=  if _then_else  (b,  first  (11  ,e)  ,  first  (12,  e)  ; 


parameteri zed  speciJ 


■»  o  i  r>  r\  1 

j.  O  ^  w  1  v  < 


name  and  brackets  arcund  the  specified  ti  on  wiiich  is  to  b*3 
used  for  the  instantiation.  Therefore,  if  a  specif ication 


for  a  list  of  natural  numbers  was  desired.  Lists (Natural) 


would  invoke  the  parameterized  specif ication  for  list.  In 
order  for  Lists  to  be  correctly  ^evoked,  the  Nat 
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specification  must  "natch"  t..e  formal  parameters  of  Loots. 
In  Speciang,  the  sorts  are  matched  under  the  header  "ACTUAL 
S0HI3"  and  the  operators  are  matcned  under  the  header 
"ACTUAL  OPERATIONS".  Under  each  of  these  headers  the  sorts 
and  operators  that  are  to  replace  the  formal  parameters  are 
positioned  to  the  left  of  an  "IS".  The  formal  parameters  the 
actual  parameters  are  replacing  are  positioned  to  the  rignt 
of  the  "IS".  In  Speciang,  the  matching  parameters  are 
announced  at  invocation.  Using  the  natural  numhe. s 
invocation,  it  would  appear  as  follows: 

Lists  (Natural) 

UK  SHE 

ACTUAL  50BTS 

nat  IS  elem 
bool  IS  tool 
ACTUAL  OF SH AT  10 NS 
equal  IS  equal 

if_then_else  IS  if_then_else 
and  IS  and 
not  IS  not 

Note  that  the  parameterized  specif ica t ion  n  as  in 
extend  field  in  the  parameter  bloc*.  When  this  occurs,  the 
parameterized  specification  must  be  invoked  with  sorts  and 
operators  that  also  match  the  specif ications  that  were 
imported  by  the  extension.  In  the  List  example,  t.:.e  serf.: 
and  operators  in  the  Boolean  s peci f icat ion  were 
the  invocation. 


mat  che i 


IV.  SPECIFICATION  EDITOR 

In  order  to  facilitate  writing  specif ica tior.s ,  a  syntax 
directed  editor  was  designed  to  format  a  spec ificat  ...c: 
created  from  Speciang.  The  editor  is  based  upon  ideas  i ro m 
Davis  [Ref.  10]  and  HacLennan  [Ref.  11].  It  is  tahie  driver, 
in  that  a  grammar  is  input  ar.d  rarsed  into  separate  yrcv.  ac¬ 
tion  rule  trees.  The  production  trees  arc  t.i&n  used  t- 
create  a  specif ica ticn  tree.  By  usin3  the  table  me  teed, 
flexibility  is  gained  in  altering  the  grammar  v i  ::h  ou~ 
affecting  the  editor.  dacLennan’s  editor  an.,  the  idea 
presented  by  Davis  was  to  create  an  internal  tree  fro-  the 
grammar  which  was  annotated;  the  tree  was  in  a  parked  form 
which  could  be  used  to  generate  the  machine  code.  Cnc 
Specification  Editor  presented  here  was  designed  to  create  a 
syntactically  correct  specification  and  to  male  the  inter¬ 
face  with  the  user  simple  and  friendly.  The  internal  tree 
created  by  the  editor  is  not  annotated  as  prescribe!  by 
Davis  and  Maclennan.  The  editor  could  be  mouifiei  to  incor¬ 
porate  annotations  which  could  transform  the  syntax  tr-.s 
created  by  the  tree  to  an  annotated  tree.  A  gramma:,  grammar 
was  developed  for  the  parser  which  is  based  on  the  modi: me  1 
3 HE  notation  presented  in  chapter  III. 

The  grammar  used  in  the  editor  is  tne  same  as  that  in 
appendix  A  except  for  the  following: 

1.  Comments  have  not  been  incorporated. 

2.  The  input  grammar  cannot  have  selection  involving 
expressions.  for  example,  tne  following  prod  jor.ioi.. 
rule  would  not  be  acceptable  since  the  light 

side  contains  an  expression  with  the  si  lection: 

<spec_block>->  (<  param_call  Xcr  Xindent  >)  |  <sp  oi:_i  ody>) 


■■  ■  T  m  v  ■  \  ■  g  «  ..  ■  M  9  \  m  V  Ijw  Z  *  T*  r"l  1  %  C%  %  1 1  ^  1 V  *-  H."  *.  1 


'■  V  -  X 


This  restriction,  was  irposeu  for  tij  rta.in.ns;  f 
force  a  clear  display  selection  and  to  ieuui.e  t.. 
problems  involved  in  programming  the  recurs.iv 
descent  purser.  This  restriction  is  not  sevt  re  sine 
the  right  hand  side  couid  be  replaced  with 
selection  such  as  <param_call>  creating  two  ruJes: 

<module>  ->  (<par aa_caii> J <spec_body >} 
<param_call>  ->  <call_r)lock>  <cr>  <indent> 

3.  The  rules  were  modified  to  reduce  th..  number  o 
selections  available.  For  example,  the  rule  nor 
<noduie_s pec>  is  as  follows: 

<mod_spec>  ->  <spec_header><aodif iers>? <sptc_bcuy> 

This  was  combined  with  the  rule  for  <spuc_].ea<,er>  t 
create  a  rule: 

<module_St.ee>  ->  ’SPEC’  <spec_ia>  'IS*  <ir.dent> 
<cr><modifiers>?  <spec_body> 


A.  AN  EDITING  SESSION 

This  section  will  describe  an  editing  session.  If 
eaitior  is  initiated  by  entering  the  name  of  the  editor 
S^eced.  A  prompt  appears  revesting  the  name  of  tne  fi.J 
where  the  user  had  stored  a  tree  from  a  previous  e’.icfr. 
sess ion . 

The  screen  is  cleared  and  tne  first  production  rule* 
rignt  hand  side  is  displayed  on  tne  screen  in  an  "urparsea 
form.  The  video  is  then  reversed  on  the  first  nonterminal  o 
modifier  which  an  input  selection  can  effect.  Ail  of  th 
strings  which  are  displayed  in  reverse  video  ace  reiecref  t 
as  the  selector  field. 

For  example,  if  <mouuie_spec>  was  the  first  rule,  the 
the  display  would  be  as  depicted  in  Figure  4.1  . 
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SPEC  <spec  id>  IS  (<£  araa_olGck>j 
<spec_Eody> 


ITG753:  ^spec  Id? 

S  ELECTIONS: — 

s:  select  d:  selector  down  uiselector  up 
b:  cursor  up  tree  f:  cursor  down  tree 


Figure  4.1  Display  of  the  Rule  <moduie_spec> . 


In  this  instance,  the  video  for  <spec_id>  would  de  reverse 
denoting  the  selector,  ar.d  the  bottom  of  the  display  voul 
show  the  selections  available. 

The  selector  is  directly  related  to  a  selection 
sel_ptr,  which  points  to  a  node  in  the  spec!: mation  r re 
being  -edited.  The  node  at  which  the  sel_ptr  is  pointing  i 
referred  to  as  the  current  node.  The  current  node  i,  smw 
at  the  bottom  of  the  display  following  "  N'ODE:  ”.  Tepe.».’.m 
on  the  current  node  a  number  oi  different  selections  ur 
available.  The  possible  selections  a  user  can  make  Uuri.'.,  a 
editing  session  are  described  in  the  following  sections. 

1 .  "s"  Selection 

If  "s"  is  selected  and  the  current  node  is  a  ront  i.r 
miuai,  the  node  is  replaced  by  the  production  ruie  ilcnti 
fieu  by  that  nonterminal.  In  the  above  example,  id  <s.,-.-c_d  I 
is  selected,  then  the  rule  for  <spec  id>  is  inserted  ml 


••  w 


S^t-Ci-Ij-CciCiOIi  t.  IT  tr  cr  ^  SCIti  r  I 

selector  is  aivai-Cec. 


SPEC  <spec  id>  IS  Kparaai  Lloc*>)? 
<spec_clock> 


’T7CU”:  ?spec  la 5  “ 

S  ELECTIONS : ~ 

sjselect  d:selector  down  uiselector  uo  ■  :  ±\ilz  edit 
bjselector  up  tree  f:  selector  down  tree' 


SPEC  <idex.tixier>  IS 
<pardin  block> 
<spec_Elock> 


UCCE:  ^llenliiler^  ~  “ 

LECTIONS: 

select  d:seiector  down  u:selector  up 
b:seiector  up  tree  f: selector  down  tree 


Figure  4.2  Selection  of  a  Non- terminal. 

If  the  current  node  is  an  option  node,  then  the  "s’" 
selection  will  inhibit  the  display  of  the  puestion  marl  an  I 
tne  nonteraina ls/termina is  preceeding  t  ne  nodifjer  will 
become  tart  of  the  abstract  sp  ecificatio*.  tree.  A  sioiiar 


Zcoa.t  OCC  U  i.  S  Wt.cO  t  i*  t.  Current  r.  J  ic  IS  d  S  1 1 .  Ct  T-  O  T.  !'  Oui  -  a  ■  r 
—  li  t  *1  IS  C  d£  e  ,  dix  £e  x.t:CtlOnS  Wh  ic  n  alTc;  no  ..  Oix  e  T  n^v-dt 

along  with  the  selection  symbols  are  not  displayed  when  th 
desired  selection  is  made. 

Figure  4.2  shows  the  tree  before  and  after  ar.  up  fat 
where  <si.ec_id>  and  <param_bioc k>  were  selected. 

2.  "i "  selection 

The  ’’i"  or  insert  selection  is  availaile  only 
the  current  node  is  an  identifier  nonterminal  des  i  ^  .-a 
<identif ier>.  linen  this  selection  is  made,  the  :iu  ■> 
tne  screen  where  the  identifier  occupied  is  lank  e  i.  T; 
user  at  this  point  can  then  type  in  the  identifier  desired 
The  input  characters  are  then  checked  to  ensure  octree 
lexical  grammar  for  identifiers.  If  tne  input  cnaractf:  i 
incorrect,  it  will  he  ignored  and  the  elitor  will  wait  lj 
another  input.  The  input  string  can  be  terminated  witv 
input.  In  any  case  the  string  will  re  terminated  when  it 
length  exceeds  twenty  characters.  Aftar  terminating  r.. 
input  the  editor  updates  the  screen  and  advances  th 
selector. 

3.  "t"  and  "f  "  Selections 

The  "b"  and  "f"  inputs  mbve  the  selector  up  and  low 
the  screen  respectively. 

Some  nodes  the  sel_ptr  stops  on  are  not  displays.  .  - 
In  these  cases,  all  the  descendants  in  the  tree  that  ar 
eligible  are  displayed  via  the  selector.  As  an  example,  i 
<module_spec>  is  the  current  node  then  ali  of  the  d is g  la  ye 
characters  in  figure  4.2  would  be  inverted  and  < node  i  pes 
would  be  displayed  at  the  Lcttom  of  the  s.;r<.e!.  i.  f->: 
"HOD  E  : 11 . 
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a .  "u"  and  "d"  Selec  tio ns 

The  "u"  ar.d  "d"  selections  ace  similar  to  iht  "n" 
and  "f"  selections;  they  move  the  selector  up  ar.d  down  the 
screen.  The  difference  is  that  tne  "u"  and  "d"  selections 
will  move  to  the  next  displayable  node  on  the  screen.  This 
facilitates  moving  the  selector  on  the  screen. 

5.  "m"  Selection 

The  "m"  selection  is  used  when  the  current  node  a 
selection  modifier  node.  Since  the  "f",  "1",  "u"  and  ''d!' 
selector  movement  selections  will  not  allow  moving  the 
selector  into  a  modifier  node  subtree,  tne  "  m"  or  'hax-; 
selection"  key  was  created  sc  the  user  could  cove  the 
selector  over  the  desired  selection.  If  the  selector  is  cn 
the  last  selection  and  "m"  us  selected,  tr.en  the  selector 
will  move  back  to  the  first  selection.  T^e  select::  will 
remain  in  the  selection  tree  until  either  a  seiecrio,.  _  3 
made  or  the  user  makes  a  "j"  selection  to  jump  out  of  the 
selection. 

6  .  "e "  Selection 

The  "e"  selection  allows  the  user  to  "erase"  tne 
string  the  selector  is  on.  This  means  that  tne  string  will 
no  longer  be  displayed  on  the  screen.  li.e  "e1'  select  ion  is 
available  when  the  current  node  is  tne  option  node  c: 
nonaisplayed  nonterminal. 

If  the  selector  has  an  option  symbol  in  its  field, 
the  erase  selection  will  eliminate  the  ot tion  symbol, 
brackets  if  displayed,  and  the  nonterminals  and  modifiers  in 
the  selectors  field.  In  figure  4.2  if  <t iram_tlock>  was  not 
desired  and  the  selector  was  positioned  on  (<param_block>) ?, 
then  the  erase  selection  would  yield  the  following  display: 

SPEC  <identifier>  IS 
<spec_body > 
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'■'utr.  the  r,o.;t  indicated  at  the  iotr.cn  of 
s  not  a  uispoaja.o..e  no  a  e ,  the  erase  w  i  m  m  a  x  o  m  i  n  a  t  e  a  _l  j.  o  t 
the  strings  of  the  screen  which  are  in  selector's  field  and 
replace  them  with  that  node. 

7.  "r"  Selection 


The  "r"  selection  is  used  to  replace  an  option  no it 
in  the  display  or  a  selection  node.  Ir.  the  previous  example 
for  erase,  if  the  sei_ptr  was  positioned  in  tee  specifica¬ 
tion  tree  so  that  the  option  nay  he  reseiocted,  then  the  "r" 


selection  would  replace  the  option  tree  in  ths 


cif 1 cn  t i o i 


tree  and  the  display  would  Le  updated  accor  dii.^iy.  A 
selector  would  not  be  visible  in  the  case  where  t».e  optio.; 
was  previously  erased.  The  replace  field  at  the  Lcttcm  of 
tne  screen  would  indicate  the  option  to  be  inserted  into  to e 
tree . 

In  the  case  that  the  option  or  selection  nas  ieen 
previously  made,  then  the  entire  portion  of  the  tree  from 
the  option  or  selection  would  be  eliminated.  The  s trines 
that  would  be  eliminated  are  in  tx;e  selector's  field.  ?cr 
example,  if  the  specification  was  as  follows: 


SPEC  <identifier>  IS 
PARA  METERS 

<s  pec_uiock.> 
DEFINED  31 

<spec_biock.  > 


and  the  current  node  was  the  "not"  displayed  option 
<param_block>?,  then  a  "r"  selection  would  yield: 


Oil- 


SPEC  <identifier>  15  (<t>aram_bioCf.>)  ? 
<spec_block> 


B.  DESIGN  OF  SPECED 


"he  editor  was  written  in  Pascal  ar.i  iap_eaent»:d  on  a 
Digital  Vax  11/780  under  the  VMS  operating  system.  The 
editing  session  described  in  the  preceeding  section  was  the 
objective  before  the  design  of  the  editor  started. 

The  design  of  the  program  was  done  ir.  a  top-down  manner. 
The  three  primary  modules  are  as  follows: 

1.  Initialization 

2.  Main  body  loor 

3.  Termination  routine 

1 .  Early  Design  Decisions 

In  order  to  simplify  the  display,  certain  nontermi¬ 
nals  are  treated  in  a  special  manner.  The  <indent>  and  <cr> 
nonterminals  are  immediately  interpreted  by  the  editor. 
These  nonterminals  mean  indent  and  carriage  return 
respectively. 

The  indent  nonterminal,  <xndent>,  before  a  nonter¬ 
minal  or  expression  means  that  the  nonterminal  ai.d  its 
descendants  will  be  indented  Ly  a  preset  tab  or  spaces  4.1  a 
carriage  return  follows. 

The  identifier  nonterminal,  <identif ier > ,  is  treated 
as  a  slot  for  inputting  a  string  of  characters.  This  stems 
reasonable  since  ail  grammars  require  identifiers.  7';* 
lexical  composition  cf  the  identifier  is  built  into  the 
editor. 

2.  Initialization 


The  first  routine  called  by  the  mam  program  is 
Initialization.  This  routine  in  turn  calls  a  routine  cai?.e.-. 
open  grammar  to  input  the  production  rules  from  a  grammar 
file.  Gpengrammar  has  a  scanner  that  pre^ recess es  t ho  in^ut 
rules  to  ensure  that  lexically  they  are  correct.  iL  "looks'' 


tr  d  CL. 
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t her.  bracketed  strings,  quoted  stria 
grammar  rules  are  put  into  a  record 
of  a  left  hard  side  arc  a  right  ran 
rules . 


r  t,  / 

d ;;  „ .  n;  e  "L 

str  uc  t  ure 
d  sice  of 


cl  in.  ->01o*  -  1 

»  rich  c o  ii  oi  -J  ts 
the  OLUCt-or. 


The  next  procedure  called  is  parsegran  mar .  T  si  o 

routine  is  a  recursive  descent  parser.  The  parser  is  based 
on  a  11(1)  gran  jar  grammar  ust-j  to  construct  tu-  ^giuci  ioi. 
rules.  The  grammar  grammar  for  the  parser  is  as  f  levs: 


<productior_rule>  ->  <nox.  ter  mi  raiXn  uie_rody> 

<ruie_Lody>  ->  ( <,<r  onter mi nal>  |<  exp  ress ior>>  ( *  *  '  j  1  +  '  l  * ' 1  ,  ; . 

<expressior.>  ->'  (’  (<rule_body>  |<ident_list>)  * )  * 

<ident_list>  ->  <nonterminal>  (*  J  '  <nonterminal>}  + 

Each  production  rule  in  the  grammar  grammar  is 
mimicked  by  a  module  in  the  recursive  descent  parser.  Tver/ 
production  rule  ir.  the  grammar  for  Speciang  is  parsed  into  a 
separate  production  rule  tree  which  describes  its  syntactic 
structure. 

figure  4.3  shows  an  abstract  production  rule  f  ae¬ 
ro  r  the  <module_spec>  production  rule. 

for  each  production  rule  tree  there  is  pointer  a.* 
array  of  pointers  to  locate  that  rule  tree.  The  rule  trees 
are  located  by  searching  the  array  for  the  root  with  a  :■  ..m*-- 
that  matches.  A  production  rule  tree  is  co.'.stru.  t:.  :  .'ra¬ 
re  cords  which  have:  pointer  and  integer  fields  follows; 
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Figure  4.3  A  Production  Rule  Tree. 


The  ’’parent"  identifies  the  name  of  rule,  string,  or 
modifier.  The  field  after  parent,  ’hen",  contains  the 
length  of  ti.e  parent  character  string.  This  feild  is  used 


This  feild  is  used 


that  rule 


points  to  the  descendants  of 
"par_ptr"  points  to  the  parent 
was  necessary  in  order  to  move 
the  abstract  tree.  The  "ch_no" 
number  that  record  node  is  or 
the  num_ch  field  indicates  the 
has.  The  ch_no  and  n um_ch 
facilitate  selector  movement, 
the  disrlay  screen.  field  tag 
There  are  seven  types  of  nodes 


ti.at  rale.  A  ;ci.r.tii  caj.--..- 
of  that  node.  This  pointe 
tne  selection  pointer  a  roan 
field  identifies  what  chii 
a  parent  record  node  wherea 
lumber  of  children  that  to  It 
fieids  were  also  created  t_ 
The  "in"  fiele  is  use. I  dor 
s  the  "tyr  e"  of  record  note, 
as  shown  in  Table  I  . 


2Z££ 

1 

2 

3 

4 
4 
6 
7 


TABLE  I 
Node  Types 


2§scriptron 
nonterr.i  nals 
modifiers-?,*,  ,  * 
terminal  strip.;? 
expression  node- 
identifier  strings 
ALT  node 
ignore  node 


The  node  tyre  has  an  effect  on  the  selectrons  available,  ho « 
the  tree  is  "unparsed"  for  display,  and  the  movement  of  the 
selection  pointer. 

After  the  rules  are  parsed  a  procedure,  get_ tree, 
will  open  the  file  of  a  specification  tree  that  was  sored 
after  a  previous  editing  session,  if  tne  user  inputs  th* 


I.dliiO  O  1  t 1~.  O 


user  stored  cr 


ir.e  initialization  routine  will  -op/  the  firs-;  pro  i  jet, 
rult  tree  ond  use  it  as  tie  root  of  the  specification  tret 
Ihe  final  steps  of  the  initialization  routine  set 
t^e  display  for  an  editing  session-  1  pointer,  prog_pi 
will  he  set  to  point  at  the  root  node.  If  a  user  specif; 
tree  is  available  then  the  rro9_Ptr  -i-s  out  to  the  root 


that  specification  tree. 


step  is  to  c ieci.r 


screen  an 


routine,  print_tree,  wnich  " u nparsos"  tne  tree  to  pro; 
ti.e  uispaay  or  tne  screen. 

Ihe  final  step  of  the  i  r.itiaii  za  ti  on  routine  .xsai 
the  selection  pointer  to  the  first  selection  of  the  :: 
If  the  initial  production  rule  was  distiayei  the  a:,  sir 
tree  would  appear  as  follows: 

<comp_spec> 


<sel_ptr>  - >  ♦ 


<inden  tXcrXmod  u  le_spec> 


Print  loutme 


The  print  routine,  which  unparses  the  specifica¬ 
tion  tree  heing  developed  and  displays  it  on  the  screen, 
deserves  further  explanation  due  to  its  complex itv .  It  rs  a 
recursive  procedure  which  does  an  inorder  traversal  of  the 
specification  tree  and,  as  it  visits  each  node,  will  respond 
according  to  that  node’s  type. 


itiltla  -_7,  t;.6  ;lO:jrr  IS  t<dSSeG  to  t  '  <-•  -Lx:.' 

routine  and  t».en  a  case  statement  determines  now  to  h an «ii e 
tie  roct  noue  and  ail  nodes  recursively  passed  to  it.  Since 
tlie  root  node  is  the  left  hand  side  of  the  first  production, 
it  is  not  displayed.  Instead,  it  treated  as  a  nondispla yen 
nonterminal  node  which  is  explained  below. 

The  predominant  factor  as  to  whether  or  not  a 
node  parent's  rielc  is  to  be  dispj.aye.x  is  the  record  uooita.. 
field  "cisp".  Only  if  the  field  is  true  will  it  bo  output  to 


the  screen. 


iiLotuer  racto*.  .or  uuap xU ^uxilx  h  i-  the 


number  o. 


tie  n out. 


rice  toe  screen  can  on-/  car 


small  fixed  number  cf  lines  cf  the  specif  lea  tiun  at  one- 
time,  a  current  line  is  assigned  for  the  display  which  will 
dictate  what  nodes  in  the  speci fica tion  will  be  snown.  If  a 
node's  "In"  field  is  m  a  particular  value  range  of  the 
•display  line  number  then  it  will  be  displayed.  Otherwise, 
even  if  the  disp  field  is  true,  it  will  not  be  displayed. 
For  example,  if  the  current  line  is  twenty,  then  all  the 
specification  nodes  whose  In  field  falls  in  the  range  twenty 
to  thirty  five  will  be  displayed. 

As  mentioned  before,  the  print  routine  respeuds 
to  a  node's  type  via  a  case  statement  which  has  seven  cases 
tuat  correspond  to  the  seven  node  types  in  Table  I. 

Case  one  handies  nonterminals.  This  case  cho  :ks: 
initially  to  see  if  the  nonterminal  is  a  carriage  return  or 
an  indent.  If  it  is  a  carriage  return,  the  screen  line 
number  is  incremented  and  the  selector  positioned  on  the 
next  line  of  the  screen.  If  the  nonterminal  is  an  indent 
symbol,  a  global  indent  counter  is  incremented  by  ore  and  nr. 
indent  flag  is  set.  Tnis  mechanism  is  use.x  to  cant  the 
nonterminal  and  its  descendants  following  the  indentation  to 
be  indented. 


Ci  S  £.*  cl  ^  t  d  OH  tu€  SCircOr**  d  ^-wOLcI-L  f  id  j  .Lei  C  iifc  Z  u\i  d  TLO  S*^*-  X; 

the  preceding  nonterminal  was  an  indentation.  If  it  was, 
then  the  global  flag  is  set  to  off  and  a  local  flag  is 
turned  on.  After  the  nonterminal  or  its  descendants  are 
displayed,  the  local  flaa  is  checked.  If  the  fias  is  on,  tr.  = 
number  of  immediately  preceeding  indentations  are  subtracted 
from  an  indentation  counter  and  the  local  flag  is  turned 
off.  Using  this  method,  the  indentation  affects  only  the 
nonterminal  or  the  expression  following  it.  For  example,  if 
the  rule  for  <mo iui e_s gec>  was: 

<mo«iuie_spec>  ->  SPEC  <spec_id>  15 

{<indent><cr><paran_bioc/.M  ? 

<ina  ent><cr><spec_block> 

The  initial  display  would  be  as  follows: 

SPEC  <spec_id>  IS  (<param__bloc>  >}  ? 
<spec_block> 

When  <param_block>  is  expanded  the  indentation  will  affect 
all  of  its  descendants  so  that  the  display  would  appear  as 
follows : 


SPEC  <spec_id>  IS 
PAH  A  M.  El  EES 

<sp  ec_b!ock> 

DEFINED  31 

<s p  ec_biock> 

Note  that  <spec_t!ock>  is  indented  by  two.  This  happened 
because  the  rule  for  <param_Llocit>  has  an  <indent>  at  ine 
end  and  the  rule  for  < mod ule_spec>  nas  an  <iudent> 
preceeding  it.  If  <para m_b 1 cck>  was  eliminated,  then 
<spec_biock>  would  only  be  indented  by  one. 


If  ti.e  aone  passed  to  the  prin  t  routine  as  no  t  .i 
carriage  return  or  indent,  it  en  the  loo  lean  field  "disi"  is 
tested  for  displayability.  If  the  field  is  true  tnen  the 
node’s  parent  field  is  written  to  the  screen.  If  the  nonter¬ 
minal  is  not  to  be  displayed,  then  a  recursive  call  is  made 
to  the  print  routine  for  each  of  the  pointers  in  tat-  "child" 
field  of  that  node. 

Case  two  handies  all  the  modifier  nodes.  If  a 
selection  modifier  node  is  encountered  and  is  to  ; >• 
displayed,  the  print  routine  will  display  a  Li  tne  selec¬ 
tions  and  place  the  ”1”  symbol  between  the  choices.  Ail  t La- 
other  modifier  nodes  will  have  a  recursive  call  to  t.vu  print 
routine  on  their  descendants.  After  returning  from  ti.e 
recursive  call,  the  node  is  checked  to  see  if  it  is  to  be 
displayed.  This  is  how  the  postfixing  of  the  modifier 
symbols  is  accomplished. 

Case  three  handles  the  template  nodus.  These  are- 
nodes  that  have  strings  that  are  required  in  the  grammar. 
For  example,  every  module  must  have  the  string  "SPiC”  and 
tne  string  "IS"  on  the  first  line.  These  nodes  have  no 
descendants  and  so  the  print  routine  will  not  n a k o  in; 
recursive  calls  on  the  descendants. 

Case  four  deals  with  expression  nodes.  An 
expression  node  is  used  to  point  to  the  descendants;  its 
only  function  is  to  allow  the  print  routine  to  auhe  r-;C  ir- 
sive  calls  on  each  descendant.  If  a  global  flag  is  set  ii: 
the  case  two  condition  indicating  the  expression  is  followed 
by  a  modifier,  tiien  brackets  surrounding  the  expression  w  .11 
be  displayed. 

Case  five  prints  the  identifier  nodes.  These  ire 
terminal  strings  for  identifiers  an  1  are  treated  like  tne 
case  three  nodes. 

Case  six  deals  with  the  "ALT"  aoies.  This  node 
is  used  to  store  trees  such  as  options  and  selections  after 
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these  rcut£  have  ieen  acted  or..  It  also  retu:..;  the  ;'lrtr.v. 
and  alternation  trees.  Normally  the  ALT  node  has  rvo  descen¬ 
dant  nodes.  The  left  one  is  for  the  branch  leading  to 
displayed  strings.  The  right  one  is  for  storing  tne  option, 
selection,  Kleene  and  alternation  trees  or  it  a  1 y  point  to 
another  ALT  node.  The  print  routine  will  recursively  call 
each  of  the  children  nodes. 

Case  seven  is  the  ignore  case.  This  is  used  when 
the  node  and  its  descendants  are  to  be  ignored.  For  exan.  he, 
in  the  case  where  the  option  node  was  used  and  stored.  The 
option  expression  is  no  longer  desired  for  display  so  it  is 
given  a  type  seven. 

3  •  dain  Body  Loop. 

The  editor,  after  initialization,  enters  a  loop  in 
t.ie  main  program  body  which  inspects  the  type  node  at  which 
the  selection  pointer  is  pointing  and  calls  one  of  ei git 
routines  to  handle  that  case.  The  routines  are  shown  in 
Table  II  . 

All  of  the  routines  which  handle  the  various  node 
types  are  essentially  constructed  the  same.  A  procedure, 
sho_siection,  is  called  ia  each  routine  which  displays  the 
various  selections  available  in  that  routine  at  the  bettor, 
or  the  screen.  each  routine  then  enters  a  loop  which 

retrieves  the  input  from  the  terminal  and  deciphers  the 
input  via  a  case  statement.  If  an  invalil  character  is 
selected,  it  is  ignored  and  the  routine  loops  for  anctner 
input  . 

The  following  sections  will  discuss  the  routines  i:. 
Table  II  with  the  exception  cf  the  first  section  «:.rci. 
discusses  the  selector  movement  routines. 


TABLE  II 

Routines  called  by  ilain  Body  Loop 


Node  Type 

Nonterminal 

7 

i 

+ 

* 

ident if ier 
ALT 


Rout ine 


I d_repiace 
Option 
Selection 
Alter  nat  ior. 
K 1  e  e  n  e 
I d_deselect 
altrep 


1 

« 

I 

! 


i 

i 


i 

i 

1 

i 

I 

I 

i 

i 


a.  Selector  Movement  Routines 

There  are  four  routines  used  to  position  tho 
selection  pointer  on  a  node  in  the  specification  tree  i r. 
concert  with  the  selector  on  the  screen.  They  each  corre¬ 
spond  to  one  of  the  four  selections,  "u",  "d",  r ,  and  :iL!, 
available  in  all  the  routines  shown  in  Table  II  .  er.  ’ 
or  "u"  inputs  are  received,  cne  of  two  routines  will  to 
called  to  move  selection  pointer  and  the  selector  to  the 
next  display  able  selection  either  down  or  up  ts.e  jco  -r. ; 
this  means  the  selection  pointer  will  be  at  a  node  t:.ac  is 
visille  on  the  display. 

The  Mb"  or  "f"  inputs  move  the  selector  backward 
or  forward  to  any  node  in  the  specif ication  tree  that  is 
available  for  modification.  These  two  inputs  also  have  two 
separate  routines  which  move  the  selection  pointer  in  the 
tree.  The  "b"  and  "f"  selections  allow  the  interior  notes. 


which  are  not  displayed  on  the  screen 
alteration. 


to  be  available  for 


! 
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designer  so  tio  t  t  r.e  y  « i  1  x  not  ^  JoitiC'  t r  e  ~  e  c  _  i 
I  pointer  on  "EX?"  nodes,  modifier  nodes  ,  if  tney  uv^  been 

k 

erased  or  selected.  and  terminal  type  three  nodes  t'^at 
contain  strings  use!  in  the  -jranaar.  Ihe  nondisplayed  codi¬ 
fier  nodes  are  accessed  in  a  different  manner.  After  tr - 
|  selection  pointer  is  moved,  the  current  node  is  checked  to 

determine  if  it  is  on  tne  screen.  If  it  is  not,  the  current 
screen  display  line  is  updated  to  position  that  node  1:.  the 
center  line  of  the  screen.  The  print  routine  is  then  caiie d 
|  to  update  the  screen. 

bm  Replace  Routine 

The  replace  routine  acts  on  type  one  nonterminal 
^  nodes.  Two  general  cases  are  possible,  depending  on  whet. .or 

the  node  is  displayed.  In  the  case  where  the  nonterminal  is 
displayed,  the  replace  routine  enables  the  user  to  add  to 
the  specif ication  tree  the  production  rule  tree  indicated  by 
|  the  nonterminal  node’s  parent  field.  As  mentioned  in  the 

previous  section,  this  occurs  when  an  "s"  is  input.  Figure 
4.4  shows  the  specification  tree  before  and  after  an  "s'  is 
input  and  the  selection  pointer  is  at  <spec_id>  i:.  i 
|  specification  tree. 

'■!  hen  "s"  is  selected,  a  routine  called  cl^r.  o 
locates  and  reproduces  the  the  production  rule  tr^e  for 
<spec_ii>  and  returns  a  pointer  to  tne  replace  routine.  The 
-  replace  routine  then  attaches  the  rule  tree  to  the  specifi¬ 

cation  tree.  The  <spec_id>  "disp"  field  is  then  set  to  raise 
to  inhibit  its  display. 

It  is  possible  that  the  selection  pointer  is  it 
(  a  ty^e  one  role  that  is  not  displayed;  its  disp  field  is  set 

to  false.  In  this  case,  the  displayabie  descendants  are 
shown  in  the  selector's  field.  An  option  to  erase  is  Liter 


available  to  eliminate  all  the  descendants  and  restore  the 


not  displayed  nonterminal.  This  is  accompli sh  ^  }  by  jn 

the  current  node's  child  pointer  to  nil  and  th«.  ui„t.  _itL 
to  true.  The  "NODE”  field  at  the  bottom  of  the  scree-:.  ov 
the  not  displayed  nonterminal. 

One  special  case  is  addressed  in  this  routine 
This  is  the  case  when  the  selection  pointer  at  tr.«  roo 

of  the  specif  ica  ti  on  tree.  In  this  case,  the  first  ;  ro.ac 
tiOu  rule  tree  is  duplicated  and  substituted  wuen  t. h *.• 
selection  is  made.  This  is  paramount  to  erasing  the  entir 


The  ia_replace  routine  was  create!  to  aiiow  t:.e 
user  to  input  directly  on  the  screen  the  ident ifier  rants. 
Tn is  routine  is  called  when  the  selection  node  type  is  err¬ 
and  the  nonterminal  is  <iden  tif  ier> .  When  an  "i"  is  ir.  jut,  a 
case  statement  is  executed  vhicn  determines  the  starti;.  c 
position  on  the  screen  by  inspecting  the  current  node's 
posit  field.  A  blank  is  written  to  the  screen  starting  at 
that  position.  The  routine  then  cakes  inputs  from  one 
terminal  and  places  them  in  that  node's  parent  fi^-id.  a;, 
character  input  is  checked  for  proper  lexical  grammar  and  is 
echoed  to  the  screen.  Invalid  characters  are  ignored.  Tr.e 
inputs  are  terminated  when  either  twenty  characters  have 
been  input  or  a  is  input. 

d.  Option  Routine 

The  option  routine  is  called  when  the  current 
node  is  type  two  and  the  parent  field  is  the  option  node 
modifier.  This  routine  will  allow  the  user  either  to  erase 
the  optional  expression  by  selecting  an  "e''  or  include  tne 
expression  preceding  the  modifier  by  selecting  an  "s". 

When  the  option  is  selected  or  erased  an  ,;ALI" 
node  is  inserted  into  the  option  node's  position  in  the 
tree.  The  ALT  node  is  treated  as  if  it  only  has  two  z:.^L- 
dren.  The  right  child  will  store  the  option  tret  so  taut  if 
the  user  later  desires  to  reverse  his  previous  decision  arc 
include  it/  he  can  reinsert  the  option  tree  into  its  prior 
position  in  the  tree.  The  lent  child  of  the  ALT  node  will  be 
i*ii  if  the  option  is  erased  or  will  contain  the  expression 
that  was  preceding  the  option  modifier  if  the  option  wan 
selected.  figure  4.5  shows  the  tree  before  ar.i  after  t-iu- 
selection  of  the  <param_biock>  option. 


When  the  option  is  stored  in  the  ri.jht  ci.iid,  it 
is  assigned  a  type  seven  so  that  the  print  routine  •.  ii.. 
ijnore  it  and  its  descendants. 

e.  Selection  Soutine 


The  selection  routine  is  called  when  the  selec¬ 
tion  node  is  type  two  and  the  parent  field  is  the  selection 


aocxriei .  jtca  asn  tr.e  selector  aowr.  or  sexto  tor  it  uuti:.  . 
can  net  acctss  the  descendants  c Z  a  selection  node  or  ok  tier, 
node,  the  selection  routine  was  written  to  permit  the  user 
to  designate  the  desired  string  by  usinj  the  "n"  Rev  to 
position  the  selector  over  it.  Ehen  "m"  is  input  a  case 
statement  is  executed  which  will  loop  between  the  selections 
until  either  a  selection  is  aade  or  a  "j"  is  entered  to  jump 
out  of  the  loop.  When  a  particular  nonterminal  is  selected 
the  routine  behaves  like  the  option  selection;  an  ALT  code 
is  inserted  for  the  selection  node  and  the  selection  :.cic 
and  its  descendants  are  stored  in  the  rijht  child  of  the.  ALT 
node. 

f.  Alternation  Routine 


The  alternation  routine  is  called  when  tin- 
selection  pointer  is  at  a  type  two  node  and  the  4arent  is 
the  alternation  modifier.  The  routine  allows  the  user  to 
duplicate  the  expression  or  nonterminal  preceding  the  modi¬ 
fier.  When  the  "s"  selection  is  made  an  ALT  node  is 
inserted  into  the  tree  at  the  alternation  positron.  The  left 
child  points  to  a  cloned  expression  of  the  descendants  of 

tne  alternation  modifier  and  the  rijht  child  points  to  the 

< 

original  alternation  node  and  descendants.  Rijuie  4.6  shv-ws 
the  tree  before  and  after  a  selection.  ’  'Jnl.iRe  the  op. tier, 
and  selection  routines,  the  rij..t  caiid  in  ti.is  c-se  wj.11 
not  Le  typed  seven  since  we  want  to  aj.iow  the  user  to  neks 
as  many  selections  as  he  would  lesire.  After  the  user  has 
made  at  least  one  selection,  then  the  noae  ca/i  be  erased; 
the  alternation  routine  is  written  so  that  at  ie^st  one 
selection  of  the  nonterminal  or  selection  must  he  mule. 
Tnis  is  accomplished  by  checking  if  the  alternation  no  d.:  f  rer 
is  a  child  of  an  ALT  node.  If  alternation  modifier  is,  fl.er. 
a  selection  must  have  teen  made  and  therefore  the  alterna¬ 
tion  tree  is  elidible  to  be  erased  from  the  display.  when 


<axions> 


<axioms> 


Figure  4.6  Selection  of  an  Alternation  Expression. 


g.  Kleene  Routine 

The  kleene  routine  is  executed  if  t  lu-  cur;  -.n 
node  is  type  two  and  the  parent  field  is  the  kleene  modi 
fier.  Like  the  alternation  routine,  it  allows  unlinite 
duplication  of  the  descendants  cf  the  modifier.  The  rout  in 
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io  the  the-  same  as  the  alternation  routine  exce ..  t  than  1 
allows  the  user  to  erase  the  kleene  codifier  ar.r  its  liesct.n 
dauts  even  if  a  selection  has  net  been  Bade.  "o  decompile 
this,  the  kleene  node’s  display  field  is  set  to  false  an 
the  first  descendant  is  set  to  type  seven. 

h.  Altrep  routine 

The  altrep  routine  is  called  when  ti«<-  stlecl_o 
pointer  is  on  an  ALT  node.  As  discussed  before,  the  ALT  rod 
is  used  to  handle  cases  for  the  option,  selection,  ultima 
tion,  and  kleene  routines.  Consequently  tne  altrep  rojt.r, 
handies  two  cases;  one  case  is  when  the  ALT  node  is  t.h 
result  of  action  taken  on  an  option  or  selection  node  an 
the  other  case  is  when  the  ALT  node  is  th<j  result  of  actio 
taken  on  an  alternation  or  kleere  node. 

If  the  ALT  node  was  the  result  of  action  take- 
on  an  option  or  selection  node  tnen  the  case  statement  wii 
permit  the  user  to  erase  the  left  tree,  eliminate  the  Ah 
node  and  place  the  option  or  selection  tree  in  the  speem 
cation  tree  in  its  former  position.  Figure  4.7  shows  -b 
result  of  reseiecting  the  <param_block>  option  which 
the  <param_Llock>  option  tree  in  its  previous  position. 

The  case  where  the  ALT  node  was  the  result  o 
action  on  an  alternation  or  kleene  node  has  two  sulcusts 
Cue  case  is  where  the  ALT  node  proceeds  another  ALT  red 
such  as  follows: 

sel_ptr  - >  ALT 


/  \ 


<sort_id>  + 

<sort  id> 
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h-' 


F- 

I 


Figure  4.7  Reselecting  the  <param_block>  Option. 


In  this  instance,  a  selection  is  available  to  eliminate  the 
ALT  node,  its  left  child  an  1  all  of  the  left  chile's  -ienc-n- 
dants.  In  this  way  the  user  may  eliminate  selections  ::  s;'. 
before. 

The  other  possibility  is  where  the  MZ  :.cl-  is 
adjacent  to  a  kleene  or  alternation  node  as  follows: 
sei_ptr  - >  ALT 


able  and  if  the  kieene  or  alternation  node  baa  leer  <.n;.  .d , 
a  replace  selection  is  available  to  redisplay  tne  hleeze  or 
alternation  node  and  its  descendants.  ibis  is  done  by 
setting  the  alternation  or  Kleene  node's  first  descendant- 
type  field  to  seven  and  the  bisr  field  to  true. 

4 .  inat ion 

After  the  user  inputs  a  "g"  to  guit  the  eii*:.n; 
session,  the  editor  exits  the  main  body  loo^  an  i  then  cn_is 
a  termination  routine.  This  routine  may  call  two  differ  er'-. 
routines  depending  on  the  users  desires: 

1.  Store  Tree 

2.  Pretty  Print 

a.  Store  Tree 

This  recursive  routine  performs  ar.  inorder  trav¬ 
ersal  of  the  specification  tree  to  store  the  fields  of  each 
node.  It  is  called  if  the  user  answers  yes  to  a  gror.pt 
asking  if  he  wants  to  store  the  abstract  tree.  Fhen  the 
routine  is  entered,  a  file  is  opened  with  the  filename  in.^ut 
at  the  beginning  of  the  editing  session.  Each  node  of  the 
abstract  specification  tree  is  then  visited  and  its  fields 
stored  in  the  file. 

b.  Pretty  Print 

This  routine  is  called  when  the  user  answers  yes 
to  a  prompt  asking  if  he  desires  a  rretty  print:  rile  of  the 
abstract  tree.  This  file  will  be  an  unparsea  version  of  the 
abstract  specification  tree.  It  is  essentially  the  sumo 
routine  used  for  uncarsing  and  displaying  the  tret  on  cho- 
screen,  except  t.»is  routine  ignores  the  line  number  used  ;or 
display. 
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V.  SOHHABY 


Speciar. g  is  a  language  base!  on  algebras  which  i.as  th 
facilities  lor  creating  formal  specifications  that  fit  i;,-. 
criteria  estabiisned  by  Liskov  and  Zilles.  Special,  j  redact 
the  complexity  of  a  specification,  and  nar.es  a  specif  icar  io 
more  readable  and  easier  to  construct  b }  using  a  model.*, 
hierarchy;  module  specifications  are  bui^t  i  y  i  :\t  or 
otner  specification  modules  through  the  extend  modj.ii ,,r 
Parameterized  speci fications  moduies  ibit  to  ii.ir.j  nizi. 
specification  by  eliminating  redundant  sp  <=■  cx  ficatio 

modules.  Futhermore,  indentations  and  cart i ay o  retirn 
imbedded  in  the  grammar  help  to  promote  a  consistent  t  or  ms 
between  specifications.  k  consistent  format  wild  assis 
readers  of  the  specifications  developed  from  the  Special: 
grammar. 

Because  there  are  many  unresolved  issues  in  using  alee 
bras  for  specifications  which  may  effect  the  format  ar. 
grammar  of  Speclang,  a  table  driven  syntax  directed  .i  1_ 
Speced,  was  created  tc  assist  the  specifier.  Its  purpose  i 
to  create  syntactically  correct  specifications.  Furthermore 
the  design  of  the  editor  permits  the  user  to  easilj  mod  if 
the  grammar. 
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APPENDIX  A 
SPECLANG  GRAMMAR 


The  production  rules  are  written  in  a  modi/ led 
Tack.us-1-iaur  (3Kr)  notation.  An  explanation  of  the  Feta- 
symbols  used  to  produce  terminal  stria  gs  in  the  grata  3 r  ate 
as  follows: 

<  >  -  A  name  enclosed  by  pointed  brackets  indicates  a  non¬ 

terminal  in  the  grammar. 

’  *  -  Strings  in  guctes  indicate  terminal  strings. 

(  }  -  Rounded  brackets  indicate  the  scope  of  a  modifier 

symbol. 

*  -  The  Kleene  closure  modifier  may  follow  either  rounded 

brackets,  terminals  or  non-terminals.  It  means  that  zero  or 
more  of  the  expressions,  terminals  or  non-terminals  map  he 
produced. 

+  -  The  alternation  modifier  is  used  like  the  Xi^c-t.o  modi¬ 
fier.  It  means  that  one  or  more  expressions,  terminals  or 
non- terminals  may  be  produced. 

i  -  The  selection  modifier  indicates  a  choice  of  non¬ 
terminals,  terminals  or  expressions.  It  is  used  between  two 
or  more  choices.  In  order  to  clarify  the  selection,  roundel 
brackets  must  enclose  the  selection. 

?  -  The  option  modifier  indicates  that  the  terminal,  non¬ 
terminal,  or  expression  is  optional  and  car.  be  excluded. 

->  -  Ti.e  production  symbol  indicates  what  a  non-terminal  can 


A  L  reduction  rale  consists  cf  a  non-  terminal  follow-.;  ;•  y 
a  production  symbol  followed  by  an  expression.  A r  expression 
is  comprised  of  terminals,  nor.- terminals,  modifying  symbols 
and  may  include  other  expressions. 

The  grammar  for  Speclang  includes  indentation  an 
carriage  returns  to  force  a  ror matting  of  the  specif icati^r. 

A  specification  is  complete  when  ail  the  strings  in  th 
specif ication  are  terminal  strings.  This  is  accomplished  L 
starting  with  a  nonterminal  and  substituting  the  not.  ter  nine 
which  are  or.  the  rijht  hand  side  of  the  production  rule  fo 
it.  The  remaining  nonterminals  are  then  substituted  ut  ti 
all  strings  are  terminal  strings.  For  example,  staitir. 
with  the  nonterminal  <spec_moauie>  and  substituting  th 
right  hand  part  of  the  rule  results  in  the  following: 

<spec_header>  <param_ tiock>?  <spec_body> 

The  rule  for  a  speci f ication  header  is: 

<spec_heaaer>  ->  ’SPEC'  <spec_ia>  ’IS'  <new_line>  <ir.dent> 

It  right  hand  side  is  substituted  into  the  above  string  t 
produce : 

’SPEC’  <spec_id>  'IS*  <new_line>  <inuer.t>  <par  am_  block>  : 

<spec_bcdy> 

<r.ewline>  and  <indent>  are  interpreted  as  cartiate  ut  c 
and  a  tab  respectively,  except  wi.er.  they  are  in  a  r.  exp  res 
sion  followed  by  a  modifier,  and  make  the  developing  specif 
cation  appear  as: 

SPEC  <spec_id>  IS 

<param_block>?  <spec_block> 

car.  be  eliminated  t 


Since  <paraa_block>  is  optional  it 
produce: 


SPEC  <spec_id>  IS 


<spec_hody  > 

The  substitutions  are  continued  until  all  strings  nr  s. 
terminal  strings.  The  first  nonterminal  string  in  Speciang 
is  <comp_spec>.  This  denotes  a  complete  specification.  As 
mentioned  in  the  previous  section  a  specification  developed 
from  Speciang  is  made  up  of  modules.  Each  module  rn  ixself 
is  a  specif ication.  To  reflect  this  the  right  hand  side  of 
the  production  rule  for  <coap_spec>  is  <moduie_3p  ec>  +  .  Ir. 
other  words,  a  complete  specification  is  made  i;o  cf  one  >  ; 
more  specif ication  modules. 

The  production  rules  are  as  follows: 

<conplete_spec>  ->  (<module_spec><newline><ne wli r.e>) 

<mcuule_spec>  ->  <spec_header> 

(<inclent^<n€wline><param_bxOCK>)  ? 
<indent><newline><spac_bl ock> 

<spec_header>  ->  ’SPEC’  <spec_id>  *13’ 

<par dm_block>  ->  'PARAMETERS  '  <indentXnevliae> 

<sp  ec_  Hoc  k> 

'  L5FINEB_3 Y  '  <indent> 

<spec_id>  ->  <identifier> 

<spec_biock>  ->  {<exter:J_f  or  a>  <uewiii.o>;  7 

{  _ O Ou^  )  | ^ U  *-  a -i e 

<spec_body>  ->  <sort_oody>  <rewline> 

<op_body>  <;iekline> 

<axiom_bo i/> ? 

<extend_f ora>  ->  *  EX T3IJD *  <newiine> 

<inlent>  <exteiid_iist> 

1  KITH  '  <inde  r.t> 

m- 

<extend_iist>  ->  <  (<spec_id>  |< par am_call>;  '  ;  *  < new ii ue>)  ♦ 
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<■  araai_cuil>  ->  <sttc_ia>  ’  ('  <spec_id>  • ,  • 

<indent>  ’/.HERE'  <new 

<act  uai_parai;:> 

<actual_param>  ->  <actual_sort,s>  <r.ewline>  <act ual_ops> 

<  actuaI_sorts>  ->  '  ACIrJAL_SG  HTS' 

{<nt wiin  eXiLdentX £ort_id>'  IS'  <sorz_ii>’  ;  ’)  ♦ 

<actual_ops>  ->  '  ACTU  AL_OP5  • 

(<newli.Ee><indeutXop_id>  •  IS  '  <op_*i.>*  ;’)  + 

<scrt_Lody>  ->  ’SORT’  <r»ewiine> 

<indeat>  (<£ort_i  J>  ';’)♦> 

<dort_id>  ->  <ident if ier> 

<op_ijody>  ->  'OPERATIONS'  <newiine> 

<inaent>  <priiuitive_op3>  <newii;:t> 
(<indent>  <  d  erived_opo>  <:i2wlifce>)  ? 
{<inuent>  <error_ops>  <newlint>)  ? 
(<indent>  <hidden_ops>  <n*=viine>'  ? 

<pri:nitive_ops>  ->  ’  PF.IM I  IT. V  V  <riewii.ua> 

<ii;Jent>  <optr dtioas> 

<derivod_opiJ>  ->  ’DERIVE:)’  <newiine>  <indoat> 

<oper  iti.or,s> 

s  v.  4.  ~~  *  <  i'i  o  V:  ...  a  p  a  jr  a  j.  a  U 

<>• .  x'\-l*riVi_n.)S>  ->  'HIDDEN'  <Ji»j  «iJiuo>  <i:* 

<o4w.:  rat  i  or  s  > 

<opwrutior.3>  ->  (<op_fora>  ’;’  <»ewIino>)  ♦ 


■  op. 


’  v  k  J  i 


•  -> 


<sort_iist>  ->  (<  3ort_i  .!>  ('  ,’<sort  id>)*)? 

<axicjii_i.ody  >  ->  ’AXIOM’  <indent>  (<uewiina>  <dXioc£>)  ♦ 


< a :<i c i’s>  ->  <cXfreSsioi;>  '  =  '  <iiA£--iS£ion> 


<eXi  res3ior*>  ->  (<sort_id>  1  < cp_ext>) 

<op_exp>  ->  <op_id>  {•  (•  <expression> 

( ' , * <expression>) *  •)')? 


lexical  grafliinar 

<spectext>  ->  (<d*=limeter>  +  )  ?  j  (< leliEetor_pair>  *■}  ? 

<deiimeter>  ->  <cccunent>  J  *  ->  *  |  *  j  •  (•  |  j 

1  *='  I 

<non_delinete r>  ->  <identif ier>  |  <strir;g_constant> 
<identif ier>  ->  <letter>  (<letter>  |  <digit>  | '  _• )  * 
<stririg_coustant>  ->  11  1  <synbol>*  '  11 

<letter>  ->  'A,|*3,|*C*J*2*J,E,|,F,|,G,|,H,l'I,|,*J,i 

*  K»|  *L’|  «»«  |  «»M  ‘O’l’  r  2'  1'*'  I'S’I'T'  i 

»  U'  J »  V»  |  *i?»  J  *  X*  |  *Y*  |  *  L*  I  'a'  |  »b'  |  '  c’  |  ’  d  '  j 

* e»  |  »x* J J  'hf | »i»  j  « j' | • k* | *1* | *  a* J * n» j 

'o'l'j'l'i'I'r'I’s'l't'l'JTvT-Tx'l 
•y  i *  z* 

<uigit>  ->  '  0 • | • 1 » | ' 2’  j » 3»  |  ’ 4' j '5* J *6* |  ' 7' | *  3’ |  » 5 ' 

<newiine>  ->  (<cofflEent>  1  <carriage_returii>)  * 

<coaimerit>  ->  (*  !  '  {<symL)ol>  |  <  let.ttr>)  +  <carriaae_retur.:>j 

<symbol>  ->  <lettcr>  J  <digit>  |  ’  j  ’  |  '  3)'  j  •  #  '  |  '  S'  j  '  %  •  | 

i  *  J  j '  *'  J  •  ('  |  • ) ’ | •  -  *  |  j  *  +  •  j 

*  ! '  |  |  |  |  | '  J  '  'I'/'l 

I'/'i  '/'i  *  {'i  *°  *  i  •  <’  j  '>  *  I';' I 

<ii.dent>  ->(*»♦  1  <tab>) 


72 


LIST  OF  EEFEBENC23 


Tanenbaum, A.  S.,  Flint,  F.  ar.  J  Sons,  ,  "Guideline s 
for  Software  Portability",  Software  ?r  actio-.  •: 
Ct x rerience ,  Voi.  8,  2  Sard  19  7E7  "  " 


vi  i  t  >.  f  «J  •  V  •  f  .iOl'i.  f  -»  •  U.  •  -  *  •  ~  I?  /  ij  •  1  m  . 

Design  of  Data  Tvye  Speci float i  xis",  Current  Tr-.  • 

P r o<^ r i n ^  Methodology  =3!/  ?  r  c-  n  t  i  c  e  -  H  aTI  7  757T. "' 

Liskov,  E.  ti.  and  Zilies,  3.  II .  ,  "Specificutio.. 
Techniques  for  Data  Abstraction",  IEEE  Transactions  or. 
Software  Engineering,  March  197b.  ~  -  -  -- 

Fasei,  J.  H.,  ££0£ramaili.  Languages  as  Abstract  Data 
Tv pes,  Ph.D.  Tissertation.  “  Purdue  unlvefsinT 
Zarayette,  Indiana,  August  1930. 

{•iajster,  M.  E.  ,  "Limits  of  the  Algebraic  Specification 
of  Data  Types",  Sigplan  Notice  12,  10  Get  1977. 

Linden,  T.  A.,  "Specifying  Abstract  Data  Tv,.c-s  fc 
Restriction",  Software  Engineer in j  Notes  3,  2  Apri 


aursidxl ,  F. .  M. ,  Goguen,  J.  A.,  Putting  Th eerie 
Together  to  Make  Specif i cations,  international  Tom 
Conrerence  on  Artif icial~lntelir gence',  5th,  blT  1977. 


Ganzmger  , 


't  a  race  t  enz  ea  Jpe  cir  iatu;. 

T  ill  r  *  a  n  a  r  t-  i  r  i  n  r.  u-  i  >  i  ■  a  a  • '  a * 


Davis,  D.  L.  ,  Syntax  Directed  Eli  tin,,  U nguri is c 
notes  on  syntax  directed  ealtors,  June  T934. 


dacLennan,  3.  J.,  The  Automatic  Generation  of  Svnta 

Directed  Editors,  TecEnical  Totos,  Zctoaef  T977.  " 


INITIAL  DISTRIBUTION  LIST 


No.  C Of IS 

1.  Defense  Technical  Information  Center  7 

Cmaeron  Station 

Alexandria,  Virginia  22314 

2.  Librarv  Code  0142  2 

Naval  Postgraduate  School 

Monterey,  California  53043 

3.  Department  Chairman,  Cole  52  2 

Department  or  Computer  Science 

Naval  Postgraduate  School 
Monterey,  California  93543 

4.  Curricular  Officer ,  Code  37  1 

Computer  Technology  Curricular  Orrice 

Naval  Postgraduate  School 
Monterey,  California  93343 

5.  Associate  Professor  Danic-J  L.  Davis,  Cole  52'^v  ^ 

Department  of  Computer  Science 

Naval  Postgraduate  School 
Monterey,  California  93943 

6.  Professor  Gordon  H.  Bradley,  Code  523z  1 

Department  of  Computer  Science 

Naval  Postgraduate  School 
Monterey,  California  93943 

7.  Lear  Norvell  L.  Lilly  2 

VA  w  112 

FPO  San  Francisco,  California  95651 


74 


s 


DTIC 

j 


